The following sections describe the various configurations available when creating, monitoring, and managing agents within your network. The following workflows will be explained:
Learn more about agents and how to set them up in the Data Connection application.
Permissions may be managed differently on enrollments provisioned before May 27, 2023. For questions about agent management for these enrollments, contact Palantir Support.
To start managing agent creation in Control Panel, users with Organization administrator
permissions must be granted an additional workflow called Change agent creation authentication method
. This workflow permission allows administrators to opt into strict enforcement of role-based agent creation management. This enforcement is done automatically for enrollments provisioned after the above date.
Permission to create agents is administered in Control Panel. To create an agent, you must have either the Organization administrator
or Data flows administrator
role assigned to you. It is also possible to create a custom role and assign the Create agent
workflow to that role. Organization roles are managed on the Organization permissions page in Control Panel.
Learn more about managing roles in Control Panel.
In addition to the Organization-level role, you must be an Editor
or Owner
of the Project in which you want to save a newly-created agent.
After creation, Project-based roles are used to control who may view, modify, and delete the agent or assign the agent as the runtime for a specific source. This means that agent creators should ensure that the Project where the agent is stored is configured with the correct roles.
Agents communicate with both Foundry and your internal network. This means that agents need to have the correct certificates in their truststores for these connections to be established.
There are two situations that may require additional certificates to be configured on an agent:
In both cases, certificates may be added from the agent management page in the Data Connection application.
To add a certificate to an agent, navigate to the agent details page for your agent in Data Connection, then select Manage agent certificates.
From here, choose the certificate to be added, along with an alias if desired. Then, add the contents of the certificate. The certificate should be added as a string similar to the below example, including newlines but without a trailing newline character. The certificate shown below is the public certificate for https://palantir.com
.
Note that you cannot enter a certificate chain; you must enter each certificate separately.
-----BEGIN CERTIFICATE-----
MIIGXjCCBUagAwIBAgIQASByQ6gv8Z6X7wEqsyBb1DANBgkqhkiG9w0BAQsFADBY
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEuMCwGA1UE
AxMlR2xvYmFsU2lnbiBBdGxhcyBSMyBEViBUTFMgQ0EgMjAyNCBRMjAeFw0yNDA2
MTcxNjUwMTVaFw0yNTA3MTkxNjUwMTRaMBkxFzAVBgNVBAMMDioucGFsYW50aXIu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvBalUG3JFYaSiRO2
enRnEwdeGUgtal9isJfB1++LxcPwo/DP2dncK+ur7URID0TVWOqu+4vXE2mmC9jz
Kx0o/URrMoz70i6qF6/Oyq6CuOHjZINiAN0ovNBBEPNGbSVD3Xq/eWgI7PNQ8hfI
9BJ/3WVA17oSG3zEXiWP3+CiL3Wm1Gn38oOt4URBMA0hgLqyOoU3ooqYIK8Fz2K/
OxAJvq45z2lonMZFFzj5thO5dBBch26mNAacO4MvI9mhUrMZtYvGBRZoXrph4EmF
TJDo2UTYiST0Tq6ibNW+NTuv66DrqFvzOpZybNuZsS6VrisYQ4huPN9jVz7RNFhJ
aeJvbQIDAQABo4IDYTCCA10wGQYDVR0RBBIwEIIOKi5wYWxhbnRpci5jb20wDgYD
VR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNV
HQ4EFgQUuAbgKrz0fIAXR1I/89IpUMN57AgwVwYDVR0gBFAwTjAIBgZngQwBAgEw
QgYKKwYBBAGgMgoBAzA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz
aWduLmNvbS9yZXBvc2l0b3J5LzAMBgNVHRMBAf8EAjAAMIGeBggrBgEFBQcBAQSB
kTCBjjBABggrBgEFBQcwAYY0aHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vY2Ev
Z3NhdGxhc3IzZHZ0bHNjYTIwMjRxMjBKBggrBgEFBQcwAoY+aHR0cDovL3NlY3Vy
ZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NhdGxhc3IzZHZ0bHNjYTIwMjRxMi5j
cnQwHwYDVR0jBBgwFoAUrw0C0MMbnlj47zdiLecDXZ5BSoowSAYDVR0fBEEwPzA9
oDugOYY3aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0bGFzcjNkdnRs
c2NhMjAyNHEyLmNybDCCAX0GCisGAQQB1nkCBAIEggFtBIIBaQFnAHUA5tIxY0B3
jMEQQQbXcbnOwdJA9paEhvu6hzId/R43jlAAAAGQJxs/FAAABAMARjBEAiATvomb
hMrUty8Vj703fTBSzY5qDxEMI473IigiGIiXugIgbj4/j24jloGdVoedM3jb6DFw
yAXkuZD3SMHBLsEvP9gAdgDd3Mo0ldfhFgXnlTL6x5/4PRxQ39sAOhQSdgosrLvI
KgAAAZAnGz7qAAAEAwBHMEUCIAHXbm9F2rwyxD36aHoGZRrnDtgg9UDRy5UtHK6D
OrmKAiEAjfomH4CGUrkBbwD8pzt9BbC6u6gPPveYiURxFIq//RUAdgB9WR4S4Xgq
exxhZ3xe/fjQh1wUoE6VnrkDL9kOjC55uAAAAZAnG0C6AAAEAwBHMEUCIQDDOg9s
KZqzbCu0mNBQMRAv6/2HkuLjZSGMxjq/F0R1/wIgKMHBSsNgeVED+LpTcIBYgp1q
SXgbwSizE6OD+1Ewol0wDQYJKoZIhvcNAQELBQADggEBAAr/tnc9dtTfwrczP7Ok
1+tLKmFRss4/1KQgLY8Tyy45Pag53ikn2n3tSPG1OpRTSmfPhPs9/UQRtMf7f2Gk
ObSXDVpPArtFBFDfZug+j22gVSYQr6zgFJu4Y9QD1GGtICqkmTScubfnjwdffTv6
5oNY4LbVGp5yctAd80OFUXspy+oVGsvv61a1pFO+s/NXleSrqDGL1oWcFW5Uj8GH
jnTM+Lt/HupqZ/ThVSkjMOug+hB875Yf8mWvadKYBX0Ga2s51cp8CI49FRswziY6
3oXPKfHHQybpIKhGosuSyzY8pL8UofHNp8gicAV80Vj6Mw+L8gWaAkCR6YnzQIyJ
9lc=
-----END CERTIFICATE-----
After modifying certificates, the agent must be restarted before changes will take effect. If certificates are added before the initial setup, they will be included in the download link after being added in Data Connection.
Certificates for connecting to your Foundry instance are included in the default agent install bundle. Generally, this means that no additional certificates will be required for your agent host to communicate with Foundry.
If traffic from your agent to Foundry is intermediated with an explicit or transparent proxy, certificates for the proxy may need to be added to the agent as part of initial setup. Since missing certificates in this scenario will prevent the agent from being managed by Foundry, these certificates must be added to the agent before downloading the initial install bundle.
If there are certificate-related errors on agent startup that prevent the agent from communicating with Foundry, these will appear in a logfile called <bootvisor_directory>/var/service.log
.
If you encounter an error when attempting to set up your agent for the first time or know in advance that additional certificates will be required, you should:
If your additional certificate is for an explicit proxy, additional configuration may be required.
Once an agent successfully connects to Foundry, these certificates should not need to be changed unless your network configuration between the agent host and Foundry changes.
When using an agent as an agent worker runtime you may need to add certificates to allow connectivity to specific target systems. This is described in more detail in the agent worker configuration reference documentation.
If you perform TLS inspection on traffic on the host where your agent is installed, you will need to manually import your root CA to the Agent Manager's truststore before the Agent Manager can connect to Foundry for the first time.
To do this, follow the instructions below:
openssl s_client -showcerts -connect FOUNDRY_URL:443
.<agent-manager-install-directory>/var/security
.cd <agent-manager-install-directory>/jdk/amazon-corretto*
../bin/keytool -import -alias <CERT_NAME> -file /path/to/certificate.pem -keystore ../../var/security/truststore.jks
(when prompted, the password is truststore
).Connected to Agent Manager, but no connection from agent
on the agent detail page in Data Connection, confirming that the Agent Manager has successfully connected to Foundry.When configuring your agent for the first time, or when connecting to a remote source, you may need to configure a proxy depending on your organization's network configuration. A proxy may be used to manage communication from the agent to Foundry, or it may be needed to reach data sources within your network.
For your agent to use a proxy, you will need to configure the proxy in both the Agent and Bootstrapper configurations found in the Advanced tab of the Manage Configuration window in the agent configuration page within Data Connection. Make sure to provide the hostname without http://
at the beginning.
The Agent Manager proxy configuration must be added to the <agent-manager-install-directory>/var/conf/runtime.yml
file on the host where the agent was installed. Below is an example Agent Manager configuration snippet with a proxy-configuration
block:
Copied!1 2 3 4 5 6 7 8 9
service-discovery: services: magritte-coordinator: ... proxy-configuration: hostAndPort: proxy-host.com:3128 credentials: # these are optional username: USERNAME password: PASSWORD
This proxy will be used by the Agent Manager to connect back to Foundry's magritte-coordinator
. It will not be used for connections from the agent to sources.
Once you have configured the Agent Manager proxy you can then configure the bootstrapper proxy. To do this, navigate to the agent configuration page within Data Connection, toggle the Advanced option in the Manage Configuration section, and finally select the Bootstrapper tab. Below is an example bootstrapper configuration snippet with a proxyConfiguration
block:
Copied!1 2 3 4 5 6 7
coordinator: proxyConfiguration: host: HOST port: PORT credentials: # these are optional username: USERNAME password: PASSWORD
Once you have updated the configuration, you must save your changes and restart the agent for them to take effect.
This proxy will be used by the Bootstrapper for connecting back to Foundry's magritte-coordinator
. It will not be used for connections from the agent to sources.
For connecting from an agent to a data source through a proxy, configure the agent's JVM-level proxy on the Bootstrapper from the Bootstrapper tab in the Advanced section of the Manage Configuration page.
Use these JVM flags:
agent:
jvmArguments: >-
-Dhttp.proxyHost=<PROXY URL> -Dhttp.proxyPort=<PROXY PORT>
-Dhttps.proxyHost=<PROXY URL> -Dhttps.proxyPort=<PROXY PORT>
This configuration affects all outbound network requests from the agent. We recommend using source-specific proxy configuration when available.
Once you set up an agent in Data Connection, you can view metrics and monitor health to maintain performance.
Navigate to the agent page in Data Connection, then select the Metrics tab. The metrics available for your agent include, but may not be limited to, the following:
Hover over the metric cards for timestamped details, and select the top right corner of the card to expand a detailed view.
The Time until next expiration in agent keystore and Time until next expiration in agent truststore metrics refer to the time until the earliest certificate expiration in the agent keystore and truststore, respectively. For example, if the agent's keystore has two certificates, one that expires in a week and one that expires in a month, the number would be 1w
as that is the closest expiration date.
The agent keystore and truststore include certificates added by users as well as those automatically added by the Agent Manager. Agent Manager certificates are automatically upgraded.
If the certificate has already expired, the metric will show 000ms
. If there are no certificates stored for the agent, the graph will be empty.
The Agent Manager version stale time and Agent version stale time metrics refer to how out of date the agent and agent manager are relative to what is available on your environment.
The version out of date metrics are calculated as the number of days between when the agent or agent manager was last updated and the release date of the latest version available. The below example illustrates how these metrics and associated monitors are expected to behave:
Day | Latest released version | Agent / Agent Manager current version | Version stale time metric value | Notes |
---|---|---|---|---|
0 | v1.0 | v1.0 | 0 | Agent updates to current latest version. |
1 | v1.0 | v1.0 | 0 | |
2 | v0.1 -> v2.0 | v1.0 | 0 -> 2 | Metric jumps to 2 when a new version is released by Palantir. |
3 | v2.0 | v1.0 | 3 | |
4 | v2.0 | v1.0 -> v2.0 | 4 -> 0 | Metric goes back to 0 after a successful update during the maintenance window. |
In this example, the agent version stale time metric on the first two days is 0
. The metric then jumps to 2
when the new version becomes available, and will then continue to increase until the next agent maintenance window, and finally drop back to 0
once an update completes successfully during a maintenance window.
If a monitor is set to send alerts when a software version becomes too old, and Palantir's new version releases are spaced more than the allowed number of days apart, this monitor will start alerting as soon as the new version is available even if there has been no opportunity for a particular agent to update. These alerts will resolve automatically after the next successful update during a maintenance window.
In the example above, if the monitor is set to alert for stale time days >2
, an alert will be issued on day 3 even though there has been no opportunity for the agent to upgrade to the latest version. The alert will automatically resolve after the successful update on day 4.
Health monitors allow you to configure alerts of varying severities (high, medium, or low) for any metric when certain conditions or thresholds are met.
You can monitor an agent's health by creating a monitoring view in the Data Health application. A monitoring view is a collection of monitoring rules that are of particular interest to a subscribed group of users.
You can view existing monitoring views by selecting the Monitoring views tab.
After selecting a specific monitoring view, you can configure the health monitors of an agent by selecting Manage monitors. From this page, you can create a new monitoring rule.
In the Create monitoring rules page, you can configure specific rules and alerts of varying severities.
Learn more about tracking data health with monitors and integrating monitors with PagerDuty.
The Data Connection agent service is regularly updated with security, stability, and performance improvements. The best way to ensure that agents receive these important improvements in a timely manner is to configure upgrade windows for each agent in use. The sections below describe what happens during an upgrade window and provide best practice guidelines.
An agent upgrade window is a set of time intervals during which it is considered safe for the agent to be temporarily offline. These time intervals recur weekly and can be defined on the Maintenance Window page in the Agent settings tab for the given agent in the Data Connection application.
The Data Connection coordinator monitors agents and their respective upgrade windows; they will perform automatic upgrades of agents during these upgrade windows when new versions are available.
As part of the upgrade, the agent will be restarted. This will terminate any running jobs and briefly prevent new jobs from running on the agent.
Agent upgrade windows should be at least 60 minutes long. However, the actual upgrade should be relatively short; it should take approximately the same amount of time as a restart of the agent.
To ensure minimal impact to data pipelines, we recommend assigning at least two agents to all Data Connection sources and to stagger upgrade windows for any given set of sources running on those agents. For example, one agent could have an upgrade window defined on Sundays, while the other has an upgrade window scheduled for Wednesdays. This ensures that during any given agent's upgrade window, jobs that are interrupted can be retried on the partner agent, and new jobs can continue to queue and run until the agent being upgraded is fully back online.
When staggered upgrade windows cannot be used, it is important to schedule upgrade windows during periods of low (ideally zero) activity. In this case, dataset syncs should be scheduled such that they finish before the start of the upgrade window or start several minutes after the window (to account for the restart occurring towards the end of the window).
Follow the steps below to move an agent to a new installation directory for the same machine.
Running
status.Running 14 minutes ago
), and then choosing Cancel build from the build page. Ensure that sync owners are appropriately notified if you need to cancel their syncs./
and modify these to what the new path will be.
Stop (Unsafe)
.
Unsafe
label is meant to warn that stopping the agent will interrupt any running syncs, which is why we took the precautions detailed in Step 1.-- sudo -su palantir
or -- sudo -su admin
.cd
../service/bin/init.sh stop
. ./service/bin/auto_restart.sh clear
../var/data/binaries
, ./var/data/cache
, and ./var/data/processes
folders to reduce the amount of data being transferred.mv <source directory> <new installation directory>
../service/bin/init.sh start
.When moving an agent to a new host, make sure that the new host meets the operating system requirements and has the same operating system and architecture as the previous agent. The new host must also have the same firewall network configurations as the old host. For example, if the agent was previously running on a linux distribution running on an x86_64 architecture, the new host can have any distribution of linux, but must be running on the same architecture. The instructions below will not work to move an agent from Linux to Windows or to an ARM architecture. For these cases, get a new download link from the UI and proceed with a new install.
When re-installing the agent using a new download link from the UI, existing source credentials will not be able to be decrypted and must be re-entered manually. To preserve these credentials, consider the following steps to migrate the source secrets from the old agent to the new one:
<bootvisor dir>/var/data
on the old agent.source-encryption-key
and source-encryption-key.private
to the same directory (<bootvisor dir>/var/data
) on the new agent.
If the agent relies on other files in the file system, ensure they are also moved to the new agent installation to maintain proper functionality.
Follow the steps below to move an agent to a new host:
Linux hosts are the preferred option for setting up an agent. You should not use a Windows host unless there is no way to procure a Linux host or run Linux in a VM on your Windows host.
Some capabilities may not work on Windows agents, particularly when using a Windows agent as an agent worker runtime. Specifically, table exports are not supported on Windows agents and will fail to run.
Follow the steps in the guide to setting up a agent, but select Windows as your operating system on the download and configure agent step. Once you install your agent, you will need to set up a Windows scheduled task that restarts the Agent Manager on crash or machine restart, as follows:
SYSTEM
.magritte-bootvisor-win
batch file in the box for Program/script.
C:\example\path\to\folder\containing\magritte\agentmagritte-bootvisor-win-{version}\service\bin\magritte-bootvisor-win.bat
.C:\example\path\to\folder\containing\magritte\agent\magritte-bootvisor-win-{version}
.Agents may backup or cache files as part of installation, version upgrade, version downgrade, and ongoing usage. Normally, backups and cache may be safely ignored, and will be automatically deleted after 30 days. If backups and cached files are using up a higher than desired amount of disk space on the agent host, it is safe to delete them as long as this is performed outside of a maintenance window.
Backup and cache files will be found in the following sub-directories within the agent installation directory:
Sub-Directory | Usage |
---|---|
/backups | Used to store backups of the agent configuration when performing upgrades. |
/var/data/cache | Used to cache data during normal operation of the agent. |