ELO Docs
 Konfiguration und Verwaltung

# Konfiguration des Dienstes

Dieses Kapitel beschreibt die Einstellungen, die in der Konfigurationsdatei appsettings.json vorgenommen werden können.

Jeder Abschnitt enthält immer ein Beispiel, das den einzelnen Abschnitt innerhalb der vollständigen Datei beschreibt. Wenn Sie mehrere Abschnitte kombinieren möchten, müssen Sie die äußeren Klammern weglassen.

Beispiel:

{
  "Key": {            // erste zu kopierende Zeile
    "MySetting": 42
  }                   // letzte zu kopierende Zeile
}

# AzureAd

Dieser Abschnitt enthält die Einstellungen für die (statische) App-Registrierung in Microsoft Azure. Die Azure-Einstellungen können auch im ELO Repository definiert werden, siehe Konfiguration im ELO Repository gespeichert.

{
  "AzureAd": {
    // Der für die Authentifizierung verwendete Microsoft Entra ID-Endpunkt muss nur für nationale Cloud-Bereitstellungen angepasst werden.
    "Instance": "https://login.microsoftonline.com/",
    // Der Domänenname, unter dem diese Anwendung registriert ist.
    "Domain": "mydomain.onmicrosoft.com",
    // Die Anwendungs-(Client-)ID der registrierten Anwendung
    "ClientId": "00000000-0123-0123-0123-c0ffeec0ffee",
    // Die Tenant-ID der registrierten Anwendung
    "TenantId": "c0ffee00-0123-4567-4567-000000000000",
    // Für die Authentifizierung verwendeter geheimer Client-Schlüssel
    "ClientSecret": "SecretGeneratedByAzure",
    // Der Callback-Pfad, der für OAuth-Redirect-Ergebnisse verwendet wird.
    "CallbackPath": "/signin-oidc-custom",
    // Für die Authentifizierung verwendete(s) Client-Zertifikat(e).
    "ClientCertificates": [
      {
        // Zertifikat aus dem KeyVault lesen. Die folgenden Eigenschaften sollten gesetzt werden:
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://msidentitywebsamples.vault.azure.net",
        "KeyVaultCertificateName": "MicrosoftIdentitySamplesCert"
        // Zertifikat aus einer lokalen Datei lesen. Die folgenden Eigenschaften sollten gesetzt werden:
        "SourceType": "Path",
        "CertificateDiskPath": "c:\\temp\\WebAppCallingWebApiCert.pfx",
        "CertificatePassword": "password"
        // Zertifikat aus einem Windows-Zertifikatsspeicher lesen. Die folgenden Eigenschaften sollten gesetzt werden:
        "SourceType": "StoreWithDistinguishedName",
        "CertificateStorePath": "CurrentUser/My",
        "CertificateDistinguishedName": "CN=WebAppCallingWebApiCert"
        // Zertifikat aus einem Windows-Zertifikatsspeicher lesen. Die folgenden Eigenschaften sollten gesetzt werden:
        "SourceType": "StoreWithThumbprint",
        "CertificateStorePath": "CurrentUser/My",
        "CertificateThumbprint": "962D129A859174EE8B5596985BD18EFEB6961684"
        // Zertifikat aus einem Base64-kodierten String lesen. Die folgenden Eigenschaften sollten gesetzt werden:
        "SourceType": "Base64Encoded",
        "Base64EncodedValue": "MIIDHzCCAgegA.....r1n8Czew8TPfab4OG37BuEMNmBpqoRrRgFnDzVtItOnhuFTa0="
        // Falls vorhanden
        "CertificatePassword": "password"
      }
    ]
  }
}

# EloOAuth

Dieser Abschnitt enthält die Einstellungen für die Verwendung von ELOauth für die ELO Azure Administration.

{
  "EloOAuth": {
    // Die ID der OAuth-Konfiguration, die mit dem ELO Oauth-Plug-in verwendet werden soll.
    // Mit diesem Namen muss eine Konfiguration in ELO OAuth angelegt werden, damit die Authentifizierung funktioniert.
    "ConfigId": "elo_az_oauth"
  }
}

Der gewählte Name für das OAuth-Konfigurationsprofil muss auch in der Konfiguration des ELOauth Plug-ins für den Indexserver vorhanden sein.

Die OAuth-ConfigId kann auch im ELO Repository definiert werden. Weitere Informationen dazu finden Sie im Abschnitt Konfiguration im ELO Repository gespeichert.

Beachten Sie die Informationen in der Dokumentation für ELOauth (opens new window), um ein Authentifizierungsprofil zu konfigurieren.

# InstanceName

Der optionale Instanzname kann für die horizontale Skalierung des Dienstes ELO-Azure-Administration verwendet werden. Wenn Sie diesen Namen festlegen, können zusätzliche Konfigurationsdateien aus dem ELO Repository geladen werden. Weitere Informationen finden Sie im Abschnitt Konfiguration im ELO Repository gespeichert.

{
  "InstanceName": "ELOAzAdmin"
}

Beachten Sie

Es gibt keine Unterstützung für mehrere Instanzen der ELO Azure Administration, die dieselbe Datenbank verwenden.

Der Instanzname beeinflusst nur die Anwendungskonfiguration, sodass für jede Instanz eine eigene Datenbank verwendet werden kann.

# PublicBaseUrl

Dieser Eintrag enthält die öffentliche URL der ELO Azure Administration, von der aus auf die ELO Azure Administration aus dem Internet zugegriffen werden kann. Diese muss angegeben werden, damit die ELO Azure Administration richtig arbeiten kann.

{
  "PublicBaseUrl": "https://....."
}

# EnableRepositoryConfigPolling: Regelmäßige Abfrage der Konfiguration aus dem Repository

Der Wert der Einstellung EnableRepositoryConfigPolling steuert, ob die ELO Azure Administration regelmäßig die Konfiguration aus dem Repository abfragt oder nicht. Der Wert der Einstellung ist standardmäßig auf true gesetzt, was bedeutet, dass die Konfiguration regelmäßig abgefragt wird. Ist dies nicht gewollt, dann muss der Wert auf false gesetzt werden, damit die Konfiguration aus der lokalen Datei appsettings.json geladen wird.

Beachten Sie

Ändern sich die Einstellungen im Repository, muss ELO Azure Administration neu gestartet werden. Andernfalls übernimmt Microsoft Identity Web nicht die Werte wie z. B. die Client-ID oder den geheimen Client-Schlüssel. Diese Werte werden nur einmalig beim Start übernommen, danach nicht mehr.

{
  "EnableRepositoryConfigPolling": 
  //
  // Prüft in regelmäßigen Zeitabständen, ob sich die Konfiguration für die ELO Azure Administration in Repository geändert hat oder nicht.
  // Hat sich die Konfiguration geändert, dann:
  //   - wird die Konfiguration aus dem Repository geladen
  //   - der Endpunkt /api/status gibt den HTTP-Statuscode 500 mit dem HTTP-Header X-RestartNeccessary
  //     zurück. In diesem Fall muss der ELO Azure Administration Dienst neu gestartet werden
  //
  "true"
  // 
  // oder
  // 
  // Lädt einmalig die Konfiguration für die ELO Azure Administration aus dem Repository beim Start der ELO Azure Administration.
  // Spätere Änderungen können nur übernommen werden, wenn die ELO Azure Administration neu gestartet wird.
  // 
  "false"
}

# DownstreamApis

Dieser Schlüssel enthält die Konfigurationseinstellungen für alle Drittanbieter-APIs, die von der ELO Azure Administration verwendet werden.

Jede API muss eine Eigenschaft Api haben, die zur Identifizierung der API verwendet wird, aber alle zusätzlichen Eigenschaften sind spezifisch für die jeweilige konfigurierte API.

DownstreamApis:Microsoft Graph

Dieser Abschnitt enthält die spezifischen Einstellungen für den Zugriff auf die Microsoft Graph API.

{
  "DownstreamApis": [
    {
      // Fester Bezeichner für die Microsoft Graph API
      "Api": "Microsoft Graph",
      // Basis-URL für den Zugriff auf Microsoft Graph, muss nur für nationale Cloud-Bereitstellungen angepasst werden
      // HINWEIS: Derzeit wird nur der stabile Endpunkt /v1.0 unterstützt, der Endpunkt /beta ist ungetestet.
      "BaseUrl": "https://graph.microsoft.com/v1.0",
      // Die Berechtigungen, die bei der Verwendung dieser API angefordert werden sollten.
      "Scopes": "user.read",
      // Der bei der Authentifizierung mit dieser API verwendete Scope
      "DefaultGraphScope": "https://graph.microsoft.com/.default"
    }
  ]
}

# ServiceUser

Die Einstellungen für den Benutzer ELO Service, der von der ELO Azure Administration verwendet werden soll.

Dieser Benutzer muss bereits in der ELOam Instanz existieren und über administrative Rechte verfügen.

{
  "ServiceUser": {
    // Benutzer in der ELOam-Instanz, der über administrative Rechte verfügt.
    "UserName": "ELO Service",
    // Passwort für den Benutzer
    "Password": "MySecretPassword"
  }
}

# Serilog

Die aktuell verwendete Logging-Lösung von der ELO Azure Administration ist Serilog (opens new window).

In diesem Abschnitt werden die Senken und Filter für das Logging konfiguriert. Weitere Details finden Sie auf der GitHub-Seite für Serilog: Serilog.Settings.Configuration (opens new window).

Die folgende Beispielkonfiguration schreibt ein grundlegendes Log in eine fortlaufende Log-Datei.

{
  "Serilog": {
    "Using": [
      "Serilog.Sinks.File"
    ],
    "MinimumLevel": "Debug",
    "WriteTo": [
      {
        "Name": "File",
        "Args": {
          "fileSizeLimitBytes": 79857600,
          "retainedFileCountLimit": 20,
          "path": "Logs/ELOAzAdmin.log",
          "rollingInterval": "Day"
        }
      }
    ],
    "Enrich": [
      "FromLogContext",
      "WithMachineName",
      "WithThreadId"
    ],
    "Properties": {
      "Application": "ELO Azure Administration"
    }
  }
}

Alternative Beispiele für die Logging-Konfiguration finden Sie im Kapitel Templates für Logging-Konfigurationen.

# Logging

In diesem Abschnitt wird die von der ELO Azure Administration verwendete Komponente Microsoft.Extension.Logging konfiguriert.

Normalerweise leitet diese Komponente das gesamte Logging zu Serilog um, wird aber auch verwendet, um das Logging-Level einzelner Komponenten zu ändern.

Weitere Informationen finden Sie in der Microsoft-Dokumentation Configure logging without code (opens new window).

{
  "Logging": {
    "LogLevel": {
      // Information und darüber für alle unkonfigurierten Komponenten verwenden
      "Default": "Information",
      // Error und darüber für alle Microsoft Komponenten verwenden
      "Microsoft": "Error",
      // Debug und darüber für alle Elo Komponenten verwenden
      "Elo": "Debug"
    }
  }
}

# Database

Dieser Konfigurationsschlüssel legt die Datenbank fest, die von der ELO Azure Administration verwendet werden soll. Tragen Sie hier den Datenbanktyp ein, der verwendet werden soll, z. B. Postgres.

ELO Azure Administration unterstützt folgende Datenbankanbieter und verwendet für den Zugriff folgende .NET-Pakete:

Datenbank Unterstützte Versionen Provider package Wert
PostgreSQL (opens new window) 14.x oder neuer; 16.x empfohlen Npgsql.EntityFrameworkCore.PostgreSQL (opens new window) Postgres
Microsoft SQL Server (opens new window) 2016 oder neuer; 2019 empfohlen
Azure SQL		 Microsoft.EntityFrameworkCore.SqlServer (opens new window) MsSql

Nachdem Sie diesen Schlüssel gesetzt haben, müssen Sie auch den entsprechenden ConnectionString setzen.

{
  // Der Typ des Datenbankanbieters, der verwendet werden soll.
  // Muss einer der folgenden Werte sein:
  //   "Postgres"
  //   "MsSql"
  "Database": "Postgres"
}

# ConnectionStrings

Dieser Abschnitt enthält die Connection Strings, welche von verschiedenen Datenbankanbietern verwendet werden. Nur der Connection String des konfigurierten Datenbank-Providers muss gesetzt werden.

{
  "ConnectionStrings": {
    "Postgres": "User ID=myUsername;Password=myPassword;Server=mydbserver;Port=5432;Database=MyAzAdminDb;Include Error Detail=true;",
    "MsSql": "Server=mydbserver,1433;Database=MyAzAdminDb;User Id=myUsername;Password=myPassword;"
  }
}

# CORS

In diesem Abschnitt können die Einstellungen für die CORS-Filterung (Cross-Origin Resource Sharing) konfiguriert werden.

{
  "Cors": {
    // Die Liste der erlaubten Ursprünge, die auf ELO Sync zugreifen dürfen.
    // Wenn Sie alle Ursprünge zulassen möchten, sollte die Einstellung auf null oder [] gesetzt werden.
    "AllowedOrigins": [
      "https://my-elo-server:9093",
      "https://my-other-origin.com"
    ]
  }
}

# Kestrel

Dieser Konfigurationsabschnitt enthält die Einstellungen für den eingebauten Kestrel-Webserver.

Information

Damit ELO Azure Administration auf Microsoft Azure zugreifen kann, müssen die Benutzerendpunkte das HTTPS-Protokoll verwenden.

Ein HTTP-Endpunkt kann nur verwendet werden, wenn dem ELO Azure Administration-Server ein Reverse-Proxy vorgeschaltet ist und der Proxy für die Verwendung von HTTPS konfiguriert ist.

Weitere Informationen finden Sie in der Microsoft-Dokumentation Kestrel Endpoints: Configure HTTPS in appsettings.json (opens new window).

{
  "Kestrel": {
    "Endpoints": {
      "HttpsInlineCertFile": {
        "Url": "https://my-elo-azadmin-server:7224",
        "Certificate": {
          "Path": "C:\\path\\to\\certificate.pfx",
          "Password": "MySecretPassword"
        }
      }
    }
  }
}

# Repositories

In diesem Konfigurationsabschnitt werden alle ELO Repositorys aufgeführt, auf die bei Verwendung der ELO Azure Administration zugegriffen werden kann.

Ein Benutzer kann eines dieser Repositorys auswählen, wenn er sich über die Weboberfläche anmeldet.

{
  "Repositories": [
    {
      // Erforderlich; der Anzeigename für den Server in der Benutzeroberfläche
      "name": "My ELO Server",
      // Erforderlich; Ein eindeutiger Schlüssel für diesen Server. Dieser Schlüssel 
      // wird auch beim Aufruf der REST-API zur Identifizierung des Repositorys verwendet.
      "key": "MyELOServer",
      // Erforderlich; der ELOix-Endpunkt, der für den Zugriff auf das Repository verwendet werden soll
      "url": "https://my-elo-server:9093/ix-Repository1/ix",
      // Optional; die ELO Web Client-URL, die für die Vorschau oder die Verknüpfung mit vorhandenen Dokumenten verwendet wird.
      // Wenn nicht festgelegt, wird die ELO Web Client-URL aus der Eigenschaft "url" gebildet.
      "webclienturl": "https://my-elo-server:9093/ix-Repository1/plugin/de.elo.ix.plugin.proxy/web/",
      // Optional; die von diesem Repository verwendete OAuth-Callback-URL
      "oauthcallbackurl": "https://my-elo-server:9093/ix-Repository1",
      // der von diesem Repository verwendete Anmeldemodus; muss einer der folgenden Werte sein:
      // "ELOauth" - Für die Authentifizierung wird das ELOauth Plug-in verwendet, das aus Gründen der Abwärtskompatibilität bereitgestellt wird.
      // "auth2"   - Das Auth2-Plug-in wird für die Authentifizierung verwendet
      "loginmode": "auth2",
      // Cookie-Token-Exchange-URL, die zur Authentifizierung einer ELO Session unter Verwendung eines Zugangstokens verwendet wird (siehe unten)
      // Diese Eigenschaft wird ignoriert, wenn "loginmode" gesetzt ist.
      "cookietokenexchangeurl": "https://my-elo-server:9093/ix-Repository1/plugin/de.elo.ix.plugin.auth/access_token?configId=elo_sync_oauth&clientId=json&jwt_token=", 
      // Die Anmelde-URL, die verwendet wird, wenn ein Benutzer auf eine ELO Web-Benutzeroberfläche umgeleitet wird
      // ¶ClientUrl¶ wird durch die Ziel-URL ersetzt
      // Diese Eigenschaft wird ignoriert, wenn "loginmode" gesetzt ist.
      "loginurl": "https://my-elo-server:9093/ix-Repository1/plugin/de.elo.ix.plugin.auth/login/?clientUrl=¶ClientUrl¶&configId=elo_sync_oauth"
    }
  ]
}

# Beispielkonfigurationen

Im Folgenden sind einige Vorlagenkonfigurationen für Repositorys aufgeführt.

{
  "Repositories": [
    // ab ELO 23.4
    {
      "name": "My Repository",
      "key": "MyRepository",
      "url": "https://my-elo-server:9093/ix-Repository1/ix",
      "loginmode": "auth2"
    },
    // bis ELO 23.4
    {
      "name": "My Repository",
      "key": "MyRepository",
      "url": "https://my-elo-server:9093/ix-Repository1/ix",
      "loginmode": "ELOauth"
    },
    // ab ELO 23.4; mit öffentlichem Zugang zum ELO Web Client
    {
      "name": "My Repository",
      "key": "MyRepository",
      "url": "https://my-elo-server:9093/ix-Repository1/ix",
      "loginmode": "auth2",
      // Public URLs für Web & Login; selbe Domain muss verwendet werden
      "webclienturl": "https://elo.company.com/web/",
      "loginurl": "https://elo.company.com/authorize?redirect_uri=¶ClientUrl¶&response_type=none&client_id=ELOAzAdmin"
    },
    // bis ELO 23.4; mit öffentlichem Zugang zum Web Client
    {
      "name": "My Repository",
      "key": "MyRepository",
      "url": "https://my-elo-server:9093/ix-Repository1/ix",
      "loginmode": "ELOauth",
      // Public URLs für Web & Login; selbe Domain muss verwendet werden
      "webclienturl": "https://elo.company.com/web/",
      "loginurl": "https://elo.company.com/login?clientUrl=¶ClientUrl¶&configId=¶ConfigId¶"
    }
  ]
}

# Login mode

Die Eigenschaft loginmode steuert die zusätzlichen Eigenschaften, die für die Authentifizierung mit einem ELO Repository erforderlich sind.

Sie kann je nach ELOix Version und Konfiguration entweder auf ELOauth oder auth2 gesetzt werden.

  • ELOauth kennzeichnet die Verwendung des ELOauth Plug-ins zur Authentifizierung, das von ELOix Versionen vor 23.4 unterstützt wird.
  • auth2 kennzeichnet die Verwendung von ELO Modern Authentication (Auth2-Plug-in) für die Authentifizierung, das von ELOix Versionen 23.4 und später unterstützt wird.

Diese URL wird zur Authentifizierung einer ELO Sitzung mithilfe eines Zugriffstokens von Microsoft Entra ID verwendet.

Die angegebene URL kann einen Platzhalter ¶ConfigId¶ enthalten, der durch die Einstellung OAuth:ConfigId ersetzt wird.

Alternativ dazu muss der Parameter configId manuell in der URL gesetzt werden. ELO Azure Administration prüft nicht, ob die URL korrekt ist.

Wenn die Eigenschaft manuell angegeben wird, wird die Einstellung OAuth:ConfigId ignoriert und der Parameter configId muss mit der erforderlichen Konfiguration für ELO Azure Administration übereinstimmen.

Die angegebene URL muss mit dem Abfrageparameter jwt_token enden, da das Zugriffstoken einfach an das Ende angehängt wird.

Information

Je nach Anforderungen könnte sich dies in einer zukünftigen Version ändern.

Wird die Eigenschaft nicht angegeben, wird eine Standard-URL unter Verwendung der Basis-URL des ursprünglichen Authentifizierungs-Plug-ins (de.elo.ix.plugin.auth) erstellt.

Wenn ELO Modern Authentication (Auth2) für die Authentifizierung verwendet wird (standardmäßig aktiviert auf ELOix ab Version 23.4), muss diese Eigenschaft explizit angegeben werden.

Beispiel:

{
  "cookietokenexchangeurl": "https://my-elo-server:9093/ix-Repository1/plugin/de.elo.ix.plugin.rest/auth2/access_token?configId=¶ConfigId¶&clientId=json&jwt_token="
}

Der Parameter configId muss mit der Konfiguration übereinstimmen, die für die Login-Konfiguration im Plug-in verwendet wurde.

# AllowedHosts

Diese Konfigurationseinstellung definiert die Host-Filterung (opens new window), die vom eingebauten Kestrel-Server verwendet wird.

{
  "AllowedHosts": "*"
}

# Konfiguration im ELO Repository gespeichert

Die Anwendungskonfiguration kann teilweise in einem ELO Repository gespeichert werden. Aus diesem Grund muss die lokale Datei appsettings.json (oder appsettings.Production.json) eine Repository- und die Service-User-Einstellung besitzen.

ELO Azure Administration verwendet diese lokale Konfiguration, verbindet sich mit dem Repository und fügt die Arbeitsversion des folgenden JSON-Dokuments als Konfigurationsdatei ein:

// Administration // ELO Az Administration // config // appsettings.public

Wenn dieses Dokument fehlt oder keine gültige Konfiguration hat, wird sein Inhalt ignoriert und eine Warnung protokolliert.

Wenn mehrere Dokumente mit diesem Namen existieren, wird nur das erste (von ELOix ermittelte) geladen.

Wenn der InstanceName in der lokalen Konfiguration festgelegt ist, wird das folgende Konfigurationsdokument zusätzlich zu den vorherigen Konfigurationselementen geladen:

// Administration// ELO Az Administration // config // <InstanceName> // appsettings.public

Der Platzhalter <InstanceName> wird durch den Wert der Einstellung InstanceName ersetzt.

# OpenTelemetry

Die ELO Azure Administration verwendet die OpenTelemetry (opens new window)-Infrastruktur für Tracing und Überwachung des Zustands des Dienstes.

Jeder Bereich kann separat konfiguriert werden und ist im Standard deaktiviert.

# OpenTelemetry:Logging

In diesem Abschnitt wird der Logging-Exporter für OpenTelemetry unter Verwendung des OTLP-Protokolls konfiguriert.

{
  "OpenTelemetry": {
    "Logging": {
      // Ob der OTLP logging Exporter aktiviert werden soll
      "Enabled": true,
      // Der Endpunkt, an den die Logs gesendet werden sollen.
      "Endpoint": "http://localhost:4317/v1/logs",
      // Das Protokoll, das zum Senden der Logs an den Endpunkt verwendet wird, muss einer der folgenden Werte sein:
      // "HttpProtobuf" - HTTP Protokoll welches das Protobuf Format verwendet
      // "Grpc" - gRPC Protocol (Default)
      "Protocol": "HttpProtobuf",
      // Weitere Header, die mit jeder Anfrage versendet werden sollten. Sie werden typischerweise für die Authentifizierung verwendet.
      "Headers": "Authorization: Bearer MySecret",
      // Die Exporter-Optionen
      "BatchExportProcessorOptions": {
        // Siehe unten für weitere Details
      }
    }
  }
}

# OpenTelemetry:Tracing

In diesem Abschnitt wird der Tracing-Exporter für OpenTelemetry unter Verwendung des OTLP-Protokolls konfiguriert.

{
  "OpenTelemetry": {
    "Tracing": {
      // Ob der OTLP Tracing Exporter aktiviert werden soll
      "Enabled": true,
      // Der Endpunkt, an den die Traces gesendet werden sollen.
      "Endpoint": "http://localhost:4317/v1/traces",
      // Das Protokoll, das zum Senden der Traces an den Endpunkt verwendet wird, muss einer der folgenden Werte sein:
      // "HttpProtobuf" - HTTP Protokoll welches das Protobuf Format verwendet
      // "Grpc" - gRPC Protocol (Default)
      "Protocol": "HttpProtobuf",
      // Weitere Header, die mit jeder Anfrage versendet werden sollten. Sie werden typischerweise für die Authentifizierung verwendet.
      "Headers": "Authorization: Bearer MySecret",
      // Die Exporter-Optionen
      "BatchExportProcessorOptions": {
        // Siehe unten für weitere Details
      }
    }
  }
}

# OpenTelemetry:Metrics

In diesem Abschnitt wird der Metrik-Exporter für OpenTelemetry unter Verwendung des OTLP-Protokolls konfiguriert.

{
  "OpenTelemetry": {
    "Metrics": {
      // Ob der OTLP Metriken Exporter verwendet werden soll
      "Enabled": true,
      // Der Endpunkt, an den die Metriken gesendet werden sollen.
      "Endpoint": "http://localhost:4317/v1/metrics",
      // Das Protokoll, das zum Senden der Metriken an den Endpunkt verwendet wird, muss einer der folgenden Werte sein:
      // "HttpProtobuf" - HTTP Protokoll welches das Protobuf Format verwendet
      // "Grpc" - gRPC Protocol (Default)
      "Protocol": "HttpProtobuf",
      // Weitere Header, die mit jeder Anfrage versendet werden sollten. Sie werden typischerweise für die Authentifizierung verwendet.
      "Headers": "Authorization: Bearer MySecret",
      // Die Exporter-Optionen
      "BatchExportProcessorOptions": {
        // Siehe unten für weitere Details
      }
    }
  }
}

# OpenTelemetry:*:BatchExportProcessorOptions

Dieser Abschnitt wird von allen OpenTelemetry-Exportern gemeinsam genutzt und konfiguriert den Batch-Export-Processor.

{
  "OpenTelemetry": {
    "*": {
      "BatchExportProcessorOptions": {
        // Verzögerung zwischen zwei geplanten Exporten in Millisekunden
        "ScheduledDelayMilliseconds": 5000,
        // Die Anzahl der Items pro Export Batch
        "MaxExportBatchSize": 512,
        // Die maximale Anzahl der Items in der Warteschlange, bevor weitere Items verworfen werden.
        "MaxQueueSize": 2048,
        // Der Timeout in Millisekunden, nach dem ein Export abgebrochen wird.
        "ExporterTimeoutMilliseconds": 30000
      }
    }
  }
}

# OpenTelemetry:Zipkin

In diesem Abschnitt wird der Zipkin (opens new window) Exporter konfiguriert.

{
  "OpenTelemetry": {
    "Zipkin": {
      // Wenn der Zipkin-Exporter verwendet werden soll
      "Enabled": true,
      // Der Endpunkt, an den die Traces gesendet werden sollen.
      "Endpoint": "http://localhost:9411/api/v2/spans"
    }
  }
}

# PrometheusServer

Dieser Abschnitt konfiguriert den Server für den Prometheus (opens new window) Metrik-Anbieter.

{
  "PrometheusServer": {
    // Die Endpunkt-URL, unter der die Metriken veröffentlicht werden sollen.
    // https wird aktuell nicht unterstützt
    "Endpoint": "http://localhost:9090/metrics",
    // Legt fest, ob der Zugriff über einen beliebigen Hostnamen erlaubt ist.
    "AllowAllHosts": true
  }
}
Zuletzt aktualisiert: 31. Juli 2026 um 20:28

Templates für Logging-Konfigurationen →