Skip to main content
Gå til innhold

Getting started with Loki during our test phase

The Platon team has been working over the past few months to establish a new logging service for Sikt, replacing the current solution, Humio, which will be phased out by the end of the year.

Rollout Phases​

Phase 1: Shipping logs from services on the PaaS cluster, and selected external services currently using Humio.

Phase 2: Introduce metrics and tracing via OpenTelemetry for teams interested in adopting those capabilities.

We are currently in a testing phase with volunteer teams piloting the Loki/Grafana stack. Some processes are manual for now but will be automated as we learn more.

Getting Started with Loki and Grafana​

For applications/services running on the PaaS cluster to start collecting logs:

  1. Identify the correct namespace for your application/service.

  2. Notify the Platon team (#platon) about the namespace. We also need:

    • A name for the tenant/team to assign to the tenant
    • A Microsoft group (EntraID group) that defines who should have access, so that Grafana and AuthProxy can be configured

  3. The Platon team will update Vector to route logs based on namespace.

  4. Loki will be configured with tenant separation to support multi-tenancy

Best Practice: Use one Tenant ID per product/service to ensure clear log ownership, cost tracking, and access control.

Accessing Your Logs​

🔗 Access your logs at: https://grafana.platon.sikt.no

  • You can access the logs in Grafana using Entra ID authentication
  • In Grafana, Organizations correspond to product areas in Sikt

Role-Based Access Control​

When Grafana is configured with Entra ID for authentication, you can manage user permissions using role-based group assignments. These groups can be created by team-admin.

About Role Groups in Sikt​

Role groups in Sikt represent specific roles that outline both responsibilities and needs related to an employee's work. Each role group should have a clear description that defines the scope and meaning of the role.

Key principles:

  • Role groups are designed to remain independent of specific systems and access rights
  • When establishing access control in different systems, role groups should be used to assign access based on roles rather than to individual users
  • Each role group is owned by a product area or section, which is responsible for defining the role and determining its membership
  • A role group may include individuals from across the entire organization

Examples of Role-Based Groups in Platon​

Group NameEntraID Description
ROLE_Platon OpsFull operational access for infrastructure management
ROLE_Platon Shared Resources InsightRead-only access to ingress logs and shared data. No write access

For Services Not Running on PaaS​

If your application is not running on the PaaS cluster, please contact the Platon team (#platon) for setup and guidance.

Query Performance​

For best practices on writing efficient LogQL queries and optimizing performance, see our comprehensive LogQL Best Practices Guide.