Incorrect Prometheus Volume Path

Oct 13, 2025 by wbrum.org 53 views

As a user of Mercator, I would like to express my gratitude for the hard work that has gone into creating this project. I am currently testing Mercator and have encountered a couple of minor issues with the Docker Compose instructions provided in the README under the "With Docker Compose" section. In this article, I will outline the two issues I encountered and suggest some improvements to the documentation.

Incorrect Prometheus Volume Path

The first issue I encountered was with the Prometheus volume path specified in the docker-compose.yml file. The path was incorrect, and I had to adjust it as follows:

diff
-      - ./prometheus:/etc/prometheus
+      - ./observability/prometheus:/etc/prometheus

This change was necessary to ensure that the Prometheus configuration files were correctly mounted in the container. It would be helpful to update the documentation to reflect this change, so that other users do not encounter the same issue.

Docker Secret Creation Requires Docker Swarm

The second issue I encountered was with the command used to create the Docker secret in the docker-compose.yml file:

echo "yourusername" | docker secret create grafana-admin-username -

This command requires Docker Swarm to be enabled, which was not the case in my environment. As a result, I had to revert to using a file-based secret, as shown in previous versions:

file: ~/.env.grafana-username

It would be beneficial to document both alternatives clearly: one using Docker Swarm and another without it. This would ensure that users can choose the approach that best suits their environment and needs.

Benefits of Documenting Alternatives

Documenting both alternatives for creating Docker secrets would have several benefits. Firstly, it would provide users with more flexibility and choice in how they configure their Mercator environment. Secondly, it would help to reduce the likelihood of users encountering issues due to differences in their environment. Finally, it would demonstrate a commitment to providing high-quality documentation and support for users.

Best Practices for Documenting Docker Compose Instructions

When documenting Docker Compose instructions, it is essential to consider the following best practices:

Clearly specify the requirements: Make sure to specify the requirements for running the Docker Compose instructions, including any necessary environment variables or dependencies.
Provide detailed explanations: Provide detailed explanations of each step, including any necessary commands or configuration files.
Document alternatives: Document alternative approaches or configurations, such as using Docker Swarm or file-based secrets.
Test and validate: Test and validate the instructions to ensure that they are accurate and effective.

Conclusion

In conclusion, I would like to emphasize the importance of providing high-quality documentation for Docker Compose instructions. By following best practices and documenting alternatives, users can benefit from more flexibility, choice, and reduced likelihood of encountering issues. I hope that this feedback will be helpful in improving the documentation for Mercator, and I look forward to continuing to test and use this project.

Future Improvements

In the future, I would like to see the following improvements to the documentation:

Updated Prometheus volume path: Update the documentation to reflect the correct Prometheus volume path.
Clear documentation of Docker secret creation: Clearly document both alternatives for creating Docker secrets, including the use of Docker Swarm and file-based secrets.
Additional best practices: Provide additional best practices for documenting Docker Compose instructions, such as testing and validating the instructions.

As a user of Mercator, you may have encountered some issues with the Docker Compose instructions provided in the README under the "With Docker Compose" section. In this article, we will address some of the most frequently asked questions related to the Mercator Docker Compose instructions.

Q: What is the correct Prometheus volume path?

A: The correct Prometheus volume path is ./observability/prometheus:/etc/prometheus. This path was updated to ensure that the Prometheus configuration files are correctly mounted in the container.

Q: Why does the Docker secret creation command require Docker Swarm?

A: The Docker secret creation command echo "yourusername" | docker secret create grafana-admin-username - requires Docker Swarm to be enabled. This is because Docker Swarm provides a way to manage secrets across multiple containers and services. However, if Docker Swarm is not enabled, you can use a file-based secret instead.

Q: How do I create a file-based secret?

A: To create a file-based secret, you can use the following command:

file: ~/.env.grafana-username

This will create a secret file at ~/.env.grafana-username that can be used to authenticate with Grafana.

Q: What are the benefits of using a file-based secret?

A: Using a file-based secret provides several benefits, including:

Flexibility: File-based secrets can be used in environments where Docker Swarm is not enabled.
Security: File-based secrets can be encrypted and stored securely.
Ease of use: File-based secrets are easy to create and manage.

Q: How do I document both alternatives for creating Docker secrets?

A: To document both alternatives for creating Docker secrets, you can use the following format:

# Docker Secret Creation

## Using Docker Swarm

To create a Docker secret using Docker Swarm, use the following command:

```bash
echo "yourusername" | docker secret create grafana-admin-username -

Using a File-Based Secret

To create a file-based secret, use the following command:

file: ~/.env.grafana-username

This will create a secret file at ~/.env.grafana-username that can be used to authenticate with Grafana.


**Q: What are some best practices for documenting Docker Compose instructions?**
--------------------------------------------------------------------------------

A: Some best practices for documenting Docker Compose instructions include:

*   **Clearly specifying the requirements**: Make sure to specify the requirements for running the Docker Compose instructions, including any necessary environment variables or dependencies.
*   **Providing detailed explanations**: Provide detailed explanations of each step, including any necessary commands or configuration files.
*   **Documenting alternatives**: Document alternative approaches or configurations, such as using Docker Swarm or file-based secrets.
*   **Testing and validating**: Test and validate the instructions to ensure that they are accurate and effective.

**Q: How can I contribute to the Mercator documentation?**
---------------------------------------------------------

A: If you have any suggestions or feedback for improving the Mercator documentation, please don't hesitate to reach out. You can contribute to the documentation by:

*   **Forking the repository**: Fork the Mercator repository on GitHub to make changes to the documentation.
*   **Creating a pull request**: Create a pull request to submit your changes to the Mercator documentation.
*   **Reporting issues**: Report any issues or bugs you encounter with the documentation to the Mercator team.

By contributing to the Mercator documentation, you can help make it more comprehensive and user-friendly for other users.