Monitor Vault in Google Cloud Platform with the Google Ops Agent. The Ops Agent is available on GitHub, and makes it easy to collect and ship telemetry from dozens of sources directly to your Google Cloud Platform. You can check it out here!
Below are steps to get up and running quickly with observIQ’s Google Cloud Platform integrations, and monitor metrics and logs from Vault in your Google Cloud Platform. You can check out Google’s documentation for using the Ops Agent for Vault here: https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/install-index
What signals matter?
Vault is a secrets store that can be distributed across multiple instances with a high level of encryption to securely handle data. Our integration collects metrics around the operations executed against the store as well as metrics related to token interactions. There are also audit logs related to the operation executed.
- This metric depicts the Vault RAM usage. Lower memory usage usually correlates to higher performance. If memory usage gets too high, interruptions, crashes, and data loss are possible.
- This metric is used to verify that leases are properly distributed and there are not more leases attempting access to the vault than expected.
- Operation counts
- Operation counts are monitored to ensure that operations are completed correctly and that there aren’t any unexpected operations being performed.
All of the above categories can be gathered with the Vault receiver – so let’s get started.
Before you begin
If you don’t already have an Ops Agent with the latest Vault receiver installed, you’ll need to do that first. Check out the Google Cloud Platform Ops Agent documentation for installation methods, including the one-line installer.
Configuring the Vault receiver for Metrics and Logs
Navigate to your Ops Agent configuration file. You’ll find it in the following location:
- /etc/google-cloud-ops-agent/config.yaml (Linux)
Edit the configuration file for Vault metrics as shown below:
4 type: vault
5 token: <VAULT_TOKEN>
6 endpoint: 127.0.0.1:8200
11 - vault
For Logging, add the following in the same yaml config file:
4 type: vault_audit
5 include_paths: [/var/log/vault_audit.log]
10 - vault_audit
Restart the Ops Agent with the following command:
1sudo service google-cloud-ops-agent restart
You can edit the config file for more precise control over your agent behavior, but it is not necessary. Here is a list of the most relevant editable fields that you can edit to adjust your agent:
|Required or Optional
|hostname:port of vault instance to be monitored.
|the path for metrics collection.
|Token used for authentication.
|The scheme to use for the request.
|A [time.Duration](https://pkg.go.dev/time#ParseDuration) value, such as
|Signals whether to use a secure TLS connection or not. If insecure is true TLS will not be enabled.
|Whether to skip verifying the certificate or not. A false value of insecure_skip_verify will not be used if insecure is true as the connection will not use TLS at all.
|Path to the TLS cert to use for mTLS required connections.
|Path to the TLS key to use for mTLS required connections.
|Path to the CA cert. As a client this verifies the server certificate. If empty, use system root CA.
|The log files to read.
|Log files to exclude (if
include_paths contains a glob or directory).
Viewing the metrics collected
If you followed the steps detailed above, the following Vault metrics will now be delivered to your preferred destination.
List of metrics collected:
|The number of requests handled by the Vault core.
|The average amount of time a core was the leader in high availability mode.
|The number of tokens that are leased for eventual expiration.
|The number of tokens created.
|The average time taken to revoke a token.
|The average time taken to renew a token.
|The number of audit log requests that have failed.
|The number of audit log responses that have failed.
|The amount of memory used by Vault.
|The duration of put operations executed against the storage backend.
|The duration of delete operations executed against the storage backend.
|The duration of list operations executed against the storage backend.
|The duration of get operations executed against the storage backend.
|The count of put operations executed against the storage backend.
|The count of delete operations executed against the storage backend.
|The count of list operations executed against the storage backend.
|The count of get operations executed against the storage backend.
observIQ’s monitoring technology is a game changer for organizations that care about performance and efficiency. If you’re using Vault, our solutions can make a significant difference in your infrastructure monitoring. Follow this space to keep up with all our future posts and simplified configurations for various sources. For questions, requests, and suggestions, reach out to our support team at support@observIQ.com.