Bei Slash lieben wir es, die Möglichkeiten des Typsystems von Typescript auszuloten, um unseren Code typsicherer und wartungsfreundlicher zu machen. Auch wenn nicht alle Anwendungen der Typsicherheit in der Praxis wirklich nützlich sind, finden wir sie interessant und unterhaltsam. Wenn sie die Wartbarkeit nicht beeinträchtigen, behalten wir sie gelegentlich als „Easter Eggs” in unserem Code bei.

Wenn Sie eine Lösung haben, senden Sie diese bitte an uns unter engineering@slash.com.

Überblick

Wir definieren „strukturierte“ Protokolle im Code und legen darüber hinaus entsprechende Metriken für diese Protokolle fest, mit denen wir Dashboards erstellen und automatische Warnmeldungen einrichten können. Bei Datadog wird die Definition einer Metrik für ein Protokoll als ProtokollmetrikEine Protokollmetrik wird mit Filtern und Aggregationsregeln erstellt, um zu bestimmen, wie die Metrik aus den Protokollen abgeleitet werden soll.

In unserer Codebasis verfügen wir über eine Reihe einfacher, stark typisierter Hilfsfunktionen, die die Definition neuer Protokolle und Metriken für diese erleichtern (der Code, den Sie auf der rechten Seite sehen). Wir haben auch einen „Vorschau”-Helfer für DX-Zwecke. Wenn ein Entwickler die Filter für eine Metrik konfiguriert, kann er in Echtzeit eine Vorschau der von Typescript berechneten URL anzeigen und die Ergebnisse im Browser überprüfen, um sicherzustellen, dass er die richtigen Filter anwendet.

Herausforderung

Implementieren Sie den Typ GetDatadogLogPreviewResponse damit die richtige Datadog-URL durch Typen generiert wird, wenn wir metrische VorschauDie URL im bestehenden Code ist korrekt, daher müssen Sie den Typfehler „beheben“.

Dies sind die Daten von Datadog. Dokumente wie ihre Log-Suchsyntax funktioniert. Jedes durchsuchbare Log kann auch in einer URL kodiert werden, die sie offenlegen. Im Allgemeinen funktionieren URL-kodierte Filter für Logs wie folgt:

1. Die Basis-URL lautet https://app.datadoghq.com/logs
2. Es gibt einen einzigen Abfrageparameter. Abfrage die eine URL-kodierte Zeichenfolge der gesamten Suchanfrage unterstützt.

Nachfolgend finden Sie Beispiele dafür, wie eine Eingabe -> Ausgabe aussieht. Diese listen alle Filter in einer nicht URI-kodierten Zeichenfolge auf:

1. Ziel: „Dauer gleich 100 anwenden“ -> Ausgabe: query=@Dauer:100
2. Ziel: „Dauer größer als 100 anwenden” -> Ausgabe: query=@duration:>100
3. Ziel: „apply http.status_code ist nicht 200” -> Ausgabe: query=-@http.status_code:200
4. Ziel: „http.status_code ist 200 oder 400 anwenden” -> Ausgabe: query=(@http.status_code:200 ODER @http.status_code:400)
5. Ziel: „apply http.route ist wie /api/v1/_“ -> Ausgabe: query=@http.route:/api/v1/_