analyser les données log

Un enregistrement log pourrait ressembler à ceci :

{
  "message": "54.3.120.2 2048 0"
}

Cette information est exacte, mais sa signification n’est pas vraiment intuitive. Les modèles Grok vous aident à extraire et comprendre les données télémétriques que vous souhaitez. Par exemple, un enregistrement log comme celui-ci est beaucoup plus facile à utiliser :

{
  "host_ip": "43.3.120.2",
  "bytes_received": 2048,
  "bytes_sent": 0
}

Pour ce faire, créez un modèle Grok qui extrait ces trois champs ; par exemple :

%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}

Après le traitement, votre enregistrement log comprendra les champs host_ip, bytes_received et bytes_sent. Vous pouvez désormais utiliser ces champs dans New Relic pour filtrer, facetter et effectuer des opérations statistiques sur vos données log . Pour plus de détails sur la façon d'analyser les logs avec les modèles Grok dans New Relic, consultez notre article de blog.

Si vous disposez des autorisations appropriées, vous pouvez créer des règles d'analyse dans notre interface utilisateur pour créer, tester et activer l'analyse Grok. Par exemple, pour obtenir un type spécifique de message d’erreur pour l’un de vos microservices appelé Inventory Services, vous devez créer une règle d’analyse Grok qui recherche un message d’erreur et un produit spécifiques. Pour ce faire :

1. Donnez un nom à la règle ; par exemple, Inventory Services error parsing.

2. Sélectionnez un champ existant à analyser (par défaut = message) ou entrez un nouveau nom de champ.

3. Identifiez la clause NRQL WHERE qui agit comme un pré-filtre pour le log entrant ; par exemple, entity.name='Inventory Service'. Ce pré-filtre réduit le nombre de logs qui doivent être traités par votre règle, supprimant ainsi les traitements inutiles.

4. Sélectionnez un log correspondant s'il existe, ou cliquez sur l'onglet Coller log pour coller un exemple log.

5. Ajoutez la règle d’analyse Grok ; par exemple :

   Inventory error: %{DATA:error_message} for product %{INT:product_id}

   Copier

   Où:

• Inventory error: Le nom de votre règle d'analyse
• error_message:Le message d'erreur que vous souhaitez sélectionner
• product_id: L'ID du produit pour le service d'inventaire

6. Activez et enregistrez la règle d’analyse.

   Bientôt, vous verrez que votre log de service d'inventaire est enrichi de deux nouveaux champs : error_message et product_id. À partir de là, vous pouvez effectuer des requêtes sur ces champs, créer des graphiques et des tableaux de bord, définir des alertes, etc.

   Pour plus de détails, consultez notre documentation sur l'ajout de règles d'analyse personnalisées dans l'interface utilisateur.

Le champ OPTIONAL_TYPE spécifie le type de valeur d'attribut à extraire. Si elles sont omises, les valeurs sont extraites sous forme de chaînes.

Les types pris en charge sont :

Si vous avez un log multiligne, sachez que le modèle Grok GREEDYDATA ne correspond pas aux nouvelles lignes (il est équivalent à .*).

Ainsi, au lieu d'utiliser %{GREEDYDATA:some_attribute} directement, vous devrez ajouter l'indicateur multiligne devant lui : (?s)%{GREEDYDATA:some_attribute}

Le pipeline New Relic Logs analyse vos messages log JSON par défaut, mais vous avez parfois des messages de log JSON mélangés à du texte brut. Dans cette situation, vous souhaiterez peut-être pouvoir les analyser, puis pouvoir filtrer à l’aide de l’attribut JSON. Si tel est le cas, vous pouvez utiliser le type grok json , qui analysera le JSON capturé par le modèle grok. Ce format repose sur 3 parties principales : la syntaxe grok, le préfixe que vous souhaitez attribuer à l'attribut json analysé et le type grok json . En utilisant le type grok json , vous pouvez extraire et analyser du JSON à partir de logs qui ne sont pas correctement formatés ; par exemple, si vos logs sont préfixés par une chaîne de date/heure :

2015-05-13T23:39:43.945958Z {"event": "TestRequest", "status": 200, "response": {"headers": {"X-Custom": "foo"}}, "request": {"headers": {"X-Custom": "bar"}}}

Afin d'extraire et d'analyser les données JSON de ce format log , créez l'expression Grok suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json}

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

Vous pouvez définir la liste des attributs à extraire ou à supprimer avec les options keepAttributes ou dropAttributes. Par exemple, avec l'expression Grok suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"keepAttributes": ["my_attribute_prefix.event", "my_attribute_prefix.response.headers.X-Custom"]})}

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request.headers.X-Custom: "bar"

Si vous souhaitez omettre le préfixe my_attribute_prefix , vous pouvez inclure le "noPrefix": true dans la configuration.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true})}

Si vous souhaitez omettre le préfixe my_attribute_prefix et conserver uniquement l'attribut status , vous pouvez inclure "noPrefix": true et "keepAttributes: ["status"] dans la configuration.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true, "keepAttributes": ["status"]})}

Si votre JSON a été échappé, vous pouvez utiliser l'option isEscaped pour pouvoir l'analyser. Si votre JSON a été échappé puis cité, vous devez également faire correspondre les guillemets, comme indiqué ci-dessous. Par exemple, avec l'expression Grok suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} "%{GREEDYDATA:my_attribute_prefix:json({"isEscaped": true})}"

Serait capable d'analyser le message échappé :

2015-05-13T23:39:43.945958Z "{\"event\": \"TestRequest\", \"status\": 200, \"response\": {\"headers\": {\"X-Custom\": \"foo\"}}, \"request\": {\"headers\": {\"X-Custom\": \"bar\"}}}"

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

Pour configurer le type Grok json , utilisez :json(_CONFIG_):

• json({"dropOriginal": true}): Supprimez le snippet JSON qui a été utilisé dans l'analyse. Lorsqu'elle est définie sur true (valeur par défaut), la règle d'analyse supprimera le snippet JSON d'origine. Notez que l’attribut JSON restera dans le champ de message.
• json({"dropOriginal": false}):Cela affichera la charge utile JSON qui a été extraite. Lorsqu'il est défini sur false, la charge utile complète uniquement JSON sera affichée sous un attribut nommé dans my_attribute_prefix ci-dessus. Notez que l'attribut JSON restera également dans le champ de message ici, donnant à l'utilisateur 3 vues différentes des données JSON. Si le stockage des trois versions est un problème, il est recommandé d'utiliser la valeur par défaut de true ici.
• json({"depth": 62}): Niveaux de profondeur auxquels vous souhaitez analyser la valeur JSON (par défaut 62).
• json({"keepAttributes": ["attr1", "attr2", ..., "attrN"]}):Spécifie quel attribut sera extrait du JSON. La liste fournie ne peut pas être vide. Si cette option configuration n'est pas définie, tous les attributs sont extraits.
• json({"dropAttributes": ["attr1", "attr2", ..., "attrN"]}):Spécifie l'attribut à supprimer du JSON. Si cette option de configuration n'est pas définie, aucun attribut n'est supprimé.
• json({"noPrefix": true}): Définissez cette option sur true pour supprimer le préfixe de l'attribut extrait du JSON.
• json({"isEscaped": true}): Définissez cette option sur true pour analyser le JSON qui a été échappé (ce que vous voyez généralement lorsque le JSON est transformé en chaîne, par exemple {\"key\": \"value\"})

Si votre système envoie un log de valeurs séparées par des virgules (CSV) et que vous devez les analyser dans New Relic, vous pouvez utiliser le type Grok csv , qui analyse le CSV capturé par le modèle Grok. Ce format repose sur 3 parties principales : la syntaxe Grok, le préfixe que vous souhaitez attribuer à l'attribut CSV analysé et le type Grok csv . En utilisant le type Grok csv , vous pouvez extraire et analyser le CSV du log.

Étant donné la ligne log CSV suivante à titre d’exemple :

"2015-05-13T23:39:43.945958Z,202,POST,/shopcart/checkout,142,10"

Et une règle d'analyse avec la forme suivante :

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"]})}

Analysera votre log comme suit :

log.timestamp: "2015-05-13T23:39:43.945958Z"
log.status: "202"
log.method: "POST"
log.url: "/shopcart/checkout"
log.time: "142"
log.bytes: "10"

Si vous devez omettre le préfixe « log », vous pouvez inclure le "noPrefix": true dans la configuration.

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "noPrefix": true})}

configuration des colonnes :

• Il est obligatoire d'indiquer les colonnes dans la configuration de type CSV Grok (qui doit être un JSON valide).
• Vous pouvez ignorer n'importe quelle colonne en définissant « _ » (trait de soulignement) comme nom de colonne pour la supprimer de l'objet résultant.

Options de configuration facultatives :

Bien que la configuration des « colonnes » soit obligatoire, il est possible de modifier l'analyse du CSV avec les paramètres suivants.

• dropOriginal: (La valeur par défaut est true) Supprimez le snippet CSV utilisé dans l'analyse. Lorsque la valeur est true (valeur par défaut), la règle d'analyse supprime le champ d'origine.
• noPrefix: (La valeur par défaut est false) N'inclut pas le nom du champ Grok comme préfixe sur l'objet résultant.
• separator: (Par défaut ,) Définit le caractère/la chaîne qui divise chaque colonne.
  • Un autre scénario courant est celui des valeurs séparées par des tabulations (TSV), pour cela vous devez indiquer \t comme séparateur, ex. %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "separator": "\t"})
• quoteChar: (Par défaut ") Définit le caractère qui entoure éventuellement le contenu d'une colonne.

Si votre système envoie un log contenant des adresses IPv4, New Relic peut les localiser géographiquement et enrichir l'événement de log avec l'attribut spécifié. Vous pouvez utiliser le type Grok geo , qui trouve la position d'une adresse IP capturée par le modèle Grok. Ce format peut être configuré pour renvoyer un ou plusieurs champs liés à l'adresse, tels que la ville, le pays et la latitude/longitude de l'IP.

Étant donné la ligne log suivante à titre d'exemple :

2015-05-13T23:39:43.945958Z 146.190.212.184

Et une règle d'analyse avec la forme suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}

Nous allons analyser votre log comme suit :

ip: 146.190.212.184
ip.city: North Bergen
ip.countryCode: US
ip.countryName: United States
ip.latitude: 40.793
ip.longitude: -74.0247
ip.postalCode: 07047
ip.region: NJ
ip.regionName: New Jersey
containerTimestamp:2015-05-13T23:39:43.945958Z
ISO8601_TIMEZONE:Z

configuration de la recherche :

Il est obligatoire de spécifier les champs lookup souhaités renvoyés par l'action geo . Au moins un élément est requis parmi les options suivantes.

• city: Nom de la ville
• countryCode: Abréviation du pays
• countryName: Nom du pays
• latitude: Latitude
• longitude: Longitude
• postalCode: Code postal, code zip ou similaire
• region:Abréviation d'État, de province ou de territoire
• regionName: Nom de l'État, de la province ou du territoire

Le pipeline New Relic Logs analyse votre message de log par défaut, mais parfois vous avez des messages de log formatés sous forme de paires valeur/clé. Dans cette situation, vous souhaiterez peut-être pouvoir les analyser, puis pouvoir filtrer à l'aide de l'attribut valeur clé.

Si tel est le cas, vous pouvez utiliser le type grok keyvalue , qui analysera les paires valeur-clé capturées par le modèle grok. Ce format repose sur 3 parties principales : la syntaxe grok, le préfixe que vous souhaitez attribuer à l'attribut valeur clé analysé et le type grok keyvalue . En utilisant le type grok keyvalue , vous pouvez extraire et analyser les paires valeur/clé du log qui ne sont pas correctement formatées ; par exemple, si votre log est préfixé par une chaîne date/heure :

2015-05-13T23:39:43.945958Z key1=value1,key2=value2,key3=value3

Afin d'extraire et d'analyser les données de valeur clé de ce format log , créez l'expression Grok suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyvalue()}

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
  my_attribute_prefix.key1: "value1"
  my_attribute_prefix.key2: "value2"
  my_attribute_prefix.key3: "value3"

Vous pouvez également définir le délimiteur et le séparateur personnalisés pour extraire les paires valeur-clé requises.

2015-05-13T23:39:43.945958Z event:TestRequest request:bar

Par exemple, avec l'expression Grok suivante :

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyvalue({"delimiter": " ", "keyValueSeparator": ":"})}

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request: "bar"

Si vous souhaitez omettre le préfixe my_attribute_prefix , vous pouvez inclure le "noPrefix": true dans la configuration.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyValue({"noPrefix": true})}

Le log résultant est :

containerTimestamp: "2015-05-13T23:39:43.945958Z"
event: "TestRequest"
request: "bar"

Si vous souhaitez définir votre préfixe de caractère de citation personnalisé, vous pouvez inclure « quoteChar » : dans la configuration.

2015-05-13T23:39:43.945958Z nbn_demo='INFO',message='This message contains information with spaces ,sessionId='abc123'

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:keyValue({"quoteChar": "'"})}

Le log résultant est :

"my_attribute_prefix.message": "'This message contains information with spaces",
"my_attribute_prefix.nbn_demo": "INFO",
"my_attribute_prefix.sessionId": "abc123"

Paramètres du modèle Grok

Vous pouvez personnaliser le comportement de l'analyse avec les options suivantes en fonction de vos formats log :

• délimiteur

  • Description : Chaîne séparant chaque paire de valeur clé.
  • Valeur par défaut : , (virgule)
  • Remplacement : définissez le champ delimiter pour modifier ce comportement.

• Séparateur de valeur clé

  • Description : Chaîne utilisée pour attribuer des valeurs aux clés.
  • Valeur par défaut : =
  • Remplacement : définissez le champ keyValueSeparator pour l'utilisation d'un séparateur personnalisé.

• citationChar

  • Description : Caractère utilisé pour entourer des valeurs avec des espaces ou des caractères spéciaux.
  • Valeur par défaut : " (guillemets doubles)
  • Remplacement : définissez un caractère personnalisé à l’aide de quoteChar.

• dropOriginal

  • Description : Supprime le message d'origine du log après analyse. Utile pour réduire le stockage log .
  • Valeur par défaut : true
  • Remplacement : définissez dropOriginal sur false pour conserver le message d'origine du log.

• pas de préfixe

  • Description : Lorsque true, exclut le nom du champ Grok comme préfixe dans l'objet résultant.
  • Valeur par défaut : false
  • Remplacement : activer en définissant noPrefix sur true.

• échapperChar

  • Description : Définissez un caractère d'échappement personnalisé pour gérer les caractères log spéciaux.
  • Valeur par défaut : « » (barre oblique inverse)
  • Remplacer : Personnaliser avec escapeChar.

• trimValeurs

  • Description : permet de supprimer les valeurs contenant des espaces.
  • Valeur par défaut : false
  • Remplacement : définissez trimValues sur true pour activer le rognage.

• touches de finition

  • Description : Permet de rogner les clés contenant des espaces.
  • Valeur par défaut : true
  • Remplacement : définissez trimKeys sur true pour activer le rognage.

Ajoutez logtype comme attribute. Vous devez définir le type de log pour chaque source nommée.

logs:
  - name: file-simple
    file: /path/to/file
    attributes:
      logtype: fileRaw
  - name: nginx-example
    file: /var/log/nginx.log
    attributes:
      logtype: nginx

Ajoutez un bloc de filtre au fichier .conf , qui utilise un record_transformer pour ajouter un nouveau champ. Dans cet exemple, nous utilisons un logtype sur nginx pour déclencher la règle d’analyse NGINX intégrée. Découvrez d’autres exemples de Fluentd.

<filter containers>
  @type record_transformer
  enable_ruby true
  <record>
    #Add logtype to trigger a built-in parsing rule for nginx access logs
    logtype nginx
    #Set timestamp from the value contained in the field "time"
    timestamp record["time"]
    #Add hostname and tag fields to all records
    hostname "#{Socket.gethostname}"
    tag ${tag}
  </record>
</filter>

Ajoutez un bloc de filtre au fichier .conf qui utilise un record_modifier pour ajouter un nouveau champ. Dans cet exemple, nous utilisons un logtype sur nginx pour déclencher la règle d’analyse NGINX intégrée. Découvrez d’autres exemples de Fluent Bit.

[FILTER]
    Name   record_modifier
    Match  *
    Record logtype nginx
    Record hostname ${HOSTNAME}
    Record service_name Sample-App-Name

Ajoutez un bloc de filtre à la configuration Logstash qui utilise un filtre de mutation add_field pour ajouter un nouveau champ. Dans cet exemple, nous utilisons un logtype sur nginx pour déclencher la règle d’analyse NGINX intégrée. Découvrez d'autres exemples de Logstash.

filter {
  mutate {
    add_field => {
      "logtype" => "nginx"
      "service_name" => "myservicename"
      "hostname" => "%{host}"
    }
  }
}

Vous pouvez ajouter un attribut à la requête JSON envoyée à New Relic. Dans cet exemple, nous ajoutons un attribut logtype de valeur nginx pour déclencher la règle d’analyse NGINX intégrée. En savoir plus sur l’utilisation de l’ API Logs.

POST /log/v1 HTTP/1.1
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
Accept: */*
Content-Length: 133
{
  "timestamp": TIMESTAMP_IN_UNIX_EPOCH,
  "message": "User 'xyz' logged in",
  "logtype": "nginx",
  "service": "login-service",
  "hostname": "login.example.com"
}