❓Agent FAQ
Installation Compatibility: Which Distributions Are Supported?
The agent is designed to be installable on any Linux operating system. For installation instructions, refer to the Agent Installation section.
If the agent isn't currently available for your specific Linux distribution, feel free to reach out to us at support@datasentinel.io to request assistance in deploying a new agent tailored to your needs.
The agent is not supported on Windows systems.
How does the agent establish communication with the platform?
The agent maintains communication with the platform using a secure HTTPS connection.
To enable the agent to transmit metrics, the platform employs token-based verification, ensuring the authenticity of the agent's interaction.
Is it possible to modify the listener port of the agent?
By default, the agent operates on port 8282. This port facilitates communication between the platform and the agent, as well as interactions via the CLI or the API.
You have the flexibility to personalize the port number using either the Agent CLI or the Agent API.
datasentinel set port <<port_number>>Alternatively, you can directly modify the port number in the configuration file situated at
$HOME/.datasentinel/agent.ymlPlease note:
After altering the port number, it's essential to restart the agent for the changes to take effect.
Once the agent is restarted, you can communicate with the agent API on the newly configured port.
Is it possible to automate the installation process of the agent?
Yes, you can automate the installation of the agent using various deployment tools and scripts. This allows you to streamline and replicate the installation procedure across multiple systems efficiently.
The agent is provided as a tar.gz executable file. (Refer to Agent installation section).
The process involves decompressing this file and then configuring it using either the Agent CLI or the Agent API.
How can I change the access token?
Agents require an access token for authentication and seamless communication with the platform. These tokens come with an expiration date.
Here's what you need to keep in mind:
Token Distribution: The support team will provide you with a valid token when needed. This token must be employed to update the Datasentinel platform.
Automated Token Download: Agents are designed to automatically download the new token. This process ensures that agents remain authorized to communicate effectively with the platform.
For more details, refer to the documentation section dedicated to Tokens. This information will guide you through the process of maintaining secure and uninterrupted agent-platform interactions.
Does the agent store data within each monitored PostgreSQL instance?
No, the agent does not store data within the individual PostgreSQL instances it monitors. It acts as a bridge to relay metrics and information securely to the platform, where the data is stored and processed for monitoring and analysis purposes.
How does the agent respond when the platform is unavailable?
When the agent encounters difficulties while sending its metrics—such as network failures, unavailability of the platform, or other reasons—it employs the following strategy:
Continued Metric Collection: The agent persists in collecting metrics despite the sending issues, ensuring that no data is lost during the problem.
Local Storage: The collected metrics are securely stored locally within a subdirectory named tmp for up to 2 hours.
Please Note:
Once the issue causing the sending problem is resolved, the agent acts autonomously. It recognizes the restoration of normalcy and initiates the automatic transmission of all stored metrics to the platform
What is the agent's response when a PostgreSQL instance becomes unavailable?
In the event that a PostgreSQL instance becomes unavailable for any reason, here's how the agent reacts:
Monitoring Interruption: The agent temporarily suspends its monitoring activities for the affected PostgreSQL instance.
Please Note:
After the PostgreSQL instance is once again accessible:
Automatic Reconnection: The agent detects the instance's availability and automatically reestablishes a connection.
Resumed Monitoring: Once reconnected, the agent seamlessly resumes its monitoring activities for the PostgreSQL instance.
How can I confirm the installation status of pg_stat_statements?
To verify the installation status of the pg_stat_statements extension, use the following SQL query. Refer to the pg_stat_statements Installation section for more details.
SELECT current_database(), extname FROM pg_extension WHERE extname ='pg_stat_statements';The output should display as follows:
current_database | extname
------------------+--------------------
postgres | pg_stat_statements
(1 row)This query will indicate whether the pg_stat_statements extension is installed in the internal postgres database.
What could be the reason if the agent is running but the CLI responds with "NO"?
$ps -ef | grep "datasentinel start agent" | grep -v grep
postgres 29213 1 1 14:00 ? 00:00:00 datasentinel start agent$datasentinel status agent
Copyright 2023 (c) datasentinel- All rights reserved www.datasentinel.io
================================================================================
Agent not startedBy default, the agent operates on port 8282, which is used for communication with the CLI.
Here are steps to diagnose and resolve potential issues:
Firewall Check: Ensure there are no firewall restrictions preventing communication between the CLI and the agent.
Server Name Resolution: Confirm that the server name is resolved correctly. You can use the following commands as an example:
ping `hostname`Curl and Telnet Test: Use the following commands to verify connectivity:
curl -v telnet://`hostname`:8282This should provide information about successful connection.
About to connect() to pg-sales-3420 port 8282 (#0) * Trying 127.0.0.1... * Connected to pg-sales-3420 (127.0.0.1) port 8282 (#0)If you encounter proxy errors due to the https_proxy environment variable, you can disable it:
Set
remove_proxy_os_env: truein theagentsection of the parameter file$HOME/.datasentinel/agent.yml.Restart the agent after making this change.
These steps should help you diagnose and troubleshoot any issues related to the communication between the agent and the CLI. If problems persist, consider referring to the documentation or contacting support for further assistance.
Is it possible to compel the agent to use a specific server name that will be recognized in the platform?
By default, the agent employs the system's default hostname to register on the platform. However, in cases where the server name is unknown, such as when it's not listed in DNS servers, you can utilize an environment variable to manage this scenario effectively.
Before initiating the agent and utilizing the CLI, set the following environment variable:
export DATASENTINEL_AGENT_HOST=<<ip>> or <<hostname>> or <<fqdn>>You have the flexibility to define this variable with the appropriate IP address, hostname, or fully qualified domain name (FQDN) based on your needs. This approach enables precise control over server name registration when standard hostname resolution is unavailable.
Last updated