Creare una pianificazione per eseguire automaticamente una query di ricerca salvata

Per creare task pianificati, impostare innanzitutto le autorizzazioni corrette creando i criteri IAM riportati di seguito.

1. Creare un gruppo dinamico per consentire ai task pianificati di inviare le metriche al servizio di monitoraggio da un compartimento specifico:

   ALL {resource.type='loganalyticsscheduledtask', resource.compartment.id='<compartment ocid>'}

   In alternativa, per consentire la pubblicazione delle metriche da tutti i compartimenti:

   ALL {resource.type='loganalyticsscheduledtask'}

2. Creare criteri per consentire al gruppo dinamico di eseguire le operazioni dei task pianificati nella tenancy:

   allow group <group_name> to use loganalytics-scheduled-task in tenancy
   allow dynamic-group <dynamic_group_name> to use metrics in tenancy
   allow dynamic-group <dynamic_group_name> to read management-saved-search in tenancy
   allow dynamic-group <dynamic_group_name> to {LOG_ANALYTICS_QUERY_VIEW} in tenancy
   allow dynamic-group <dynamic_group_name> to {LOG_ANALYTICS_QUERYJOB_WORK_REQUEST_READ} in tenancy
   allow dynamic-group <dynamic_group_name> to READ loganalytics-log-group in tenancy
   allow dynamic-group <dynamic_group_name> to {LOG_ANALYTICS_LOOKUP_READ} in tenancy
   allow dynamic-group <dynamic_group_name> to read compartments in tenancy

   Controllare se il gruppo di utenti dispone dell'autorizzazione di lettura/uso per la risorsa di aggregazione Management-dashboard-family nella tenancy. In caso contrario, includere la seguente istruzione criterio nel criterio creato:

   allow group <group_name> to {MANAGEMENT_SAVED_SEARCH_READ} in tenancy

• Alcune delle istruzioni dei criteri sopra riportate sono incluse nei modelli di criteri definiti da Oracle immediatamente disponibili. Si consiglia di prendere in considerazione l'utilizzo del modello per il caso d'uso. Vedere Modelli di criteri definiti da Oracle per i casi d'uso comuni.

• Per informazioni sui gruppi dinamici e sui criteri IAM, vedere Documentazione OCI: gestione dei gruppi dinamici e Documentazione OCI: gestione dei criteri.

• Per i dettagli dei criteri, vedere Building Metric Query - Prerequisiti in Oracle Cloud Infrastructure Documentation.

• Per il riferimento all'API Scheduled Tasks, consulta ScheduledTask Reference in Oracle Cloud Infrastructure API Documentation.

Per visualizzare i task schedulati per una ricerca salvata specifica, è possibile visitare la pagina dei dettagli della ricerca salvata. Tuttavia, se si desidera elencare tutti i task pianificati in un compartimento specifico senza fare riferimento alle ricerche salvate per le quali sono stati creati i task pianificati, utilizzare l'API per eseguire una query per elencare i task pianificati. Vedere ListScheduledTasks.

Specificare i seguenti parametri nel comando GET:

• taskType=SAVED_SEARCH
• compartmentId=<compartment_OCID>
• limit=1000
• sortOrder=DESC
• sortBy=timeUpdated

Per eseguire il comando, è necessario:

• Spazio di nomi: lo spazio di nomi Log Analytics specificato durante la creazione dei task pianificati.
• OCID compartimento: l'OCID del compartimento su cui si desidera eseguire una query per la lista dei task pianificati creati in esso.

È possibile monitorare l'integrità dei task schedulati della ricerca salvata mediante le metriche Stato esecuzione task schedulato nel servizio di monitoraggio. In caso di esecuzione non riuscita o saltata di un task a causa di un'anomalia dell'infrastruttura o se una risorsa o una configurazione dipendente viene modificata, la metrica fornisce i dettagli dell'errore per facilitare la correzione.

Per i passi per accedere alla metrica Stato esecuzione task pianificato, vedere Monitorare Log Analytics mediante le metriche del servizio.

Ogni task schedulato della ricerca salvata ha il proprio intervallo come specificato nella relativa schedulazione task. Una metrica viene emessa alla tenancy per ogni esecuzione di task pianificata. Passare il puntatore del mouse sui datapoint del grafico per visualizzare ulteriori dettagli sull'attività. È possibile filtrare i dati delle metriche in base a una delle dimensioni Status, DisplayName o ResourceId.

1. Aprire il menu di navigazione e fare clic su Observability & Management. In Log Analytics, fare clic su Amministrazione.

2. Le risorse di amministrazione sono elencate nel riquadro di navigazione a sinistra in Amministrazione. Fare clic su Regole di rilevamento. Nella pagina contenente l'elenco delle regole di rilevamento, fare clic sul nome della regola di rilevamento della ricerca salvata che si desidera aprire. Viene visualizzata la pagina dei dettagli della regola di rilevamento.

3. Fare clic su Metriche. Viene visualizzata la scheda Metriche.

4. Fare clic sul menu Opzioni nell'angolo superiore destro della metrica Stato esecuzione task pianificato e selezionare Visualizza in Explorer metriche.

   La metrica viene ora visualizzata in Esplora metriche. Qui è possibile visualizzare il grafico in modo più dettagliato.

   
   
   
   
   

   Far scorrere il pulsante Mostra tabella dati per visualizzare i dettagli delle metriche:

   
   
   
   
   

5. Fare clic su Modifica query e selezionare Nome dimensione e Valore dimensione per la metrica. È possibile filtrare i dati delle metriche in base a taskResult in base al risultato dell'esecuzione del task pianificato, a Status di esecuzione del task, a DisplayName del task, a queryExecTimeRange o al relativo ResourceId.

   Nota
   
   

   Per visualizzare grafici e dati in formato tabulare da Esplora metriche specificando un nome dimensione e un valore dimensione, evitare di utilizzare campi con parentesi o altri caratteri speciali nel nome. Se il campo selezionato per il nome dimensione contiene caratteri speciali, creare un campo virtuale utilizzando il comando eval o rinominare il campo esistente utilizzando il comando rename in modo che vengano rimosse le parentesi o i caratteri speciali. Ad esempio, se il campo utilizzato per Nome dimensione è Host Name (Server), è possibile creare un campo virtuale hostname con | eval hostname=“Host Name (Server)”.

   La dimensione queryExecTimeRange è utile per determinare il tempo impiegato per eseguire la query del task pianificato. I valori disponibili sono < 5s, >= 5s and < 10s, >= 10s and < 30s e > 30s. In genere, le query che richiedono più di 30 secondi per essere eseguite sono considerate costose in termini di tempo di esecuzione. Vedere How to Make Your Query Performant.

   La dimensione taskResult può avere i valori Succeeded, Failed e Paused. La dimensione Status fornisce ulteriori dettagli su taskResult. Ad esempio, se il valore di taskResult è Paused, il valore di Status può essere Paused by User.

   Fare clic su Aggiorna grafico per aggiornare la visualizzazione del grafico. Il grafico visualizzerà solo i datapoint per i quali è stato applicato il filtro.

   È possibile passare alla vista Tabella dati per una rappresentazione tabulare dei datapoint raccolti.

6. Modificare il nome della dimensione per visualizzare prospettive diverse nel grafico.

È possibile impostare avvisi per notificare lo stato tramite e-mail, SMS, Slack, PagerDuty, URL endpoint HTTPS o funzione. Vedere Creazione di avvisi per gli eventi rilevati.

Di seguito sono riportati i vari valori della dimensione status riportati tramite questa metrica per valori taskResult specifici.

Prendere nota dei seguenti fattori per la creazione di task schedulati:

• Requisiti per la composizione delle interrogazioni:

  Quando si compongono query per creare task pianificati, assicurarsi di soddisfare i requisiti riportati di seguito.

  • Le limitazioni riportate di seguito per le query delle regole di rilevamento sono riportate di seguito.

    • Evitare di eseguire la ricerca con caratteri jolly nel campo Contenuto log originale nella query task schedulata. Per ulteriori informazioni sulle ricerche con caratteri jolly, vedere Usa parole chiave, frasi e caratteri jolly.

    • Il comando timestats non può essere seguito da eval, extract, jsonextract, xmlextract e lookup.

    • Il comando regex non deve essere utilizzato in campi di grandi dimensioni come Message per evitare di rendere le query costose per l'elaborazione.

      Il confronto like e i comandi extract, jsonextract e xmlextract non sono supportati in campi di grandi dimensioni come Message.

      I campi di collegamento o i campi utilizzati nella clausola BY non possono essere utilizzati in campi di grandi dimensioni come Message.

    • The commands which are not supported in the queries for scheduled tasks are cluster, clustercompare, clusterdetails, clustersplit, compare, createview, delta, fieldsummary, highlightgroups, geostats, linkdetails, map, nlp and timecompare.

  • Limiti massimi:

    Il numero massimo di campi supportati per la clausola by è 3.

    Il numero massimo di campi supportati per il comando timestats è 3.

    Il numero massimo di funzioni aggregate supportate in una query task pianificata è 1.

  • Utilizzare i valori dei campi link come dimensioni per i parametri di contabilizzazione:

    Selezionare fino a tre campi dimensione e una metrica numerica da registrare nel servizio di monitoraggio. Per indicare quali campi devono essere inviati al monitoraggio, le query devono terminare con:

    ... | link ... | fields -*, dim1, dim2, dim3, metric1

    Il comando link contiene diverse colonne nell'output, ad esempio ora di inizio, ora di fine, conteggio e così via, per impostazione predefinita. Utilizzare -* nel comando fields per rimuovere questi campi e specificare facoltativamente fino a tre campi dimensione e un campo metrica obbligatorio.

    È possibile avere più istruzioni eval dopo il comando stats e più funzioni stats per il calcolo dei risultati intermedi. Tuttavia, la query deve terminare con fields -*, dim1, dim2, dim3, metric1 per indicare le dimensioni e la metrica da contabilizzare. Utilizzare le linee guida riportate di seguito per le query delle regole di rilevamento.

    • Usare il comando addfields fino a 2.
    • Utilizzare fino a 3 funzioni stats.
    • Le istruzioni eval sono necessarie per il calcolo dei risultati intermedi e finali.

    Query con esempi:

    'Log Source' = 'OCI Email Delivery'
     | link 'Entity'
     | addfields [ * | where deliveryEventType = r and bounceType = hard | stats count as 'hard bounces' ],
                 [ * | where deliveryEventType = e and length(ipPoolName) > 0 | stats count as 'total sent messages' ]
     | eval 'Total Rate' = ('hard bounces' / 'total sent messages') * 100
     | fields -*, 'Entity', 'Total Rate'

    'Log Source' = 'My Network Logs'
     | stats sum(Success) as TotalSuccess, sum(Failure) as TotalFailure
     | eval SuccessRate = (TotalSuccess / (TotalSuccess + TotalFailure)) * 100 | fields -*, SuccessRate

• Arresto dei log:

  Se i task pianificati vengono eseguiti prima dell'arrivo dei log, è possibile che i task pianificati non restituiscano i risultati previsti. Per evitare la mancanza di tali log nei task schedulati a causa del loro arrivo in ritardo, la query deve tenerne conto utilizzando una rettifica dell'intervallo di tempo.

  Ad esempio, se il task pianificato viene eseguito ogni 5 minuti per controllare il numero di errori di autenticazione e se vi è un ritardo di 3 minuti tra il momento in cui vengono generati i log e il momento in cui raggiungono Oracle Log Analytics, il task pianificato non rileverà i log. Si consideri che il task pianificato viene eseguito ogni 5 minuti, ad esempio 01:00, 01:05, 01:10 e così via. Se il record di log L1 generato alle ore 01:04 raggiunge Oracle Log Analytics alle ore 01:07. L1 non è stato rilevato nel task pianificato eseguito alle ore 1:05 perché il log non è arrivato a Oracle Log Analytics in questo momento. Durante l'esecuzione successiva alle 01:10, la query cerca i log con indicatori orari compresi tra le 01:05 e le 01:10. Anche in questo ciclo, L1 non viene rilevato perché ha un indicatore orario di 01:04. La query seguente potrebbe non visualizzare tutti i record di log se i log arrivano in ritardo:

  Label = 'Authentication Error' | stats count as logrecords by 'Log Source'

  Per determinare il ritardo nell'arrivo dei log in Oracle Log Analytics, calcolare la differenza tra l'indicatore orario menzionato nel record di log e l'ora di pubblicazione del processore di log. La seguente query di esempio può essere utilizzata per verificare se c'è un ritardo:

  Label = 'Authentication Error' and 'Log Processor Posting Time (OMC INT)' != null | fields 'Agent Collection Time (OMC INT)', 'Data Services Load Time', 'Process Time', 'Log Processor Posting Time (OMC INT)'

  La query seguente utilizza la funzione dateRelative per regolare il ritardo di 3 minuti in un task che viene eseguito a intervalli di 5 minuti:

  Label = 'Authentication Error' and Time between dateRelative(8minute, minute) and dateRelative(3minute, minute) | stats count as logrecords by 'Log Source'

• Altri fattori:

  • Per comprendere come le query vengono create nel servizio di monitoraggio, consulta la sezione relativa alla creazione di query sulle metriche nella documentazione di Oracle Cloud Infrastructure.

  • Prendere nota delle informazioni sui limiti per la pubblicazione dei dati delle metriche nel servizio di monitoraggio. I limiti corrispondono alle metriche per un task schedulato. Consulta PostMetricData API nella Documentazione di Oracle Cloud Infrastructure.

    Quando la ricerca salvata può generare più di 200 valori singoli per campo, i risultati parziali vengono contabilizzati a causa dei limiti imposti dal servizio di monitoraggio. In questi casi, per visualizzare i risultati in alto o in basso su 200, utilizzare il comando sort.