Grafana Labs has announced the release of Grafana Loki 3.4, introducing significant enhancements aimed at standardizing object storage configuration, providing updated sizing guidance, and improving log ingestion capabilities.
Key Features in Loki 3.4:
Thanos-Based Object Storage Client
Loki 3.4 introduces support for the Thanos Object Storage Client, aligning its storage configuration with other Grafana open-source databases like Mimir and Pyroscope. This integration allows users to reuse existing storage configurations, simplifying setup and reducing duplication. The adoption of the Thanos client is optional in this release, allowing for gradual migration. Future releases plan to make it the default storage client, deprecating existing configurations.
Updated Sizing Guidance
The release reintroduces the sizing guidance page, updated with insights from Grafana Labs’ experience running Loki to power Grafana Cloud Logs. It categorizes Loki clusters into three tiers based on expected ingestion volume and provides recommendations based on p90 resource utilization for each component. This detailed guidance assists users in determining the appropriate CPU and memory requirements for deploying Loki in microservices mode.
Enhanced Log Ingestion and Metadata Extraction
Loki’s out-of-order support has been expanded to allow ingestion of arbitrarily old log lines by enabling the time_sharding_enabled setting. Additionally, a new feature allows for the extraction of fields into structured metadata at ingestion time, facilitating more efficient log querying and analysis.
Promtail Merging into Grafana Alloy
As part of efforts to provide users with a unified telemetry collector, Promtail has been officially merged into Grafana Alloy in this release. This consolidation aims to streamline log collection and processing within the Grafana ecosystem.
Helm Chart Improvements
The Loki Helm chart has received several enhancements, including support for topologySpreadConstraints and the overrides exporter, providing users with more flexibility and control over their deployments.
Migrating from Promtail to Alloy
Migrating from Promtail to Grafana Alloy enhances your logging infrastructure by leveraging Alloy’s advanced features and unified telemetry collection capabilities.
Grafana Alloy is Grafana Labs’ distribution of the OpenTelemetry (OTel) Collector, offering a comprehensive solution for metrics, logs, and traces.
Step 1: Prepare for Migration
Before starting the migration, ensure you have the following:
- Alloy Installed: Download and install Alloy from the Grafana Alloy download page.
- Backup Your Promtail Configuration: Save a copy of your existing Promtail configuration file (promtail.yml) for reference.
- Review Documentation: Familiarize yourself with Alloy’s configuration syntax and features by reading the Alloy documentation.
Step 2: Understand Configuration Differences
it’s important to understand the differences between Promtail and Alloy configurations. While Promtail uses separate sections like server, clients, and scrape_configs, Alloy consolidates these into a unified logs section.
For example, the server block in Promtail is replaced by http_listen_port under logs in Alloy, and the clients block is replaced by a loki target within the targets section.
The scrape_configs block remains similar but is nested under logs in Alloy. These changes streamline the configuration process, making it easier to manage and maintain your logging pipeline.
Step 3: Convert Promtail Configuration to Alloy
Promtail Sample Configuration
server:
http_listen_port: 9080
clients:
– url: http://loki:3100/loki/api/v1/push
scrape_configs:
– job_name: system
static_configs:
– targets: [localhost]
labels:
job: varlogs
__path__: /var/log/*.log
Alloy Sample Configuration
logs:
– name: my-logs
http_listen_port: 9080
targets:
– loki:
url: http://loki:3100/loki/api/v1/push
scrape_configs:
– job_name: system
static_configs:
– targets: [localhost]
labels:
job: varlogs
__path__: /var/log/*.log
Step 4: Validate Your Alloy Configuration
After converting your configuration, validate it to ensure there are no syntax errors or misconfigurations.
Use the Alloy CLI:
Run the following command to validate your configuration file:
alloy validate <path-to-your-config-file>
Test in a Staging Environment:
Deploy Alloy in a non-production environment to test the configuration and ensure logs are being collected and sent to Loki as expected.
Step 5: Deploy Alloy in Production
Once you’ve validated your configuration, deploy Alloy in your production environment.
Stop Promtail:
Stop the Promtail service on all servers where it’s running.
systemctl stop promtail
Start Alloy:
Start the Alloy service using your new configuration file.
systemctl start alloy
Monitor Logs:
Use Grafana to monitor logs and ensure Alloy is functioning correctly.
Step 5 mentioned above are for the case where Alloy and Promtail are running in a single Linux Virtual machine. For a Kubernetes setup use the following Helm Chart to deploy Alloy.
Migrate the configurations as described in Step 3 and update the Alloy configuration, then stop / delete the existing Promtail setup.
Conclusion
Grafana Loki 3.4 is a game-changer for logging and observability, offering standardized storage configuration, sizing guidance, and the integration of Promtail into Alloy.
These updates make it easier than ever to manage your logging infrastructure, optimize performance, and reduce costs. Whether you’re a long-time Loki user or new to the platform, Loki 3.4 has something for everyone.
