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 metriche al servizio di monitoraggio da un compartimento specifico:

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

   In alternativa, per consentire la contabilizzazione 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

• Alcune delle istruzioni dei criteri di cui sopra 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 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 Creazione di query delle metriche - Prerequisiti nella documentazione di Oracle Cloud Infrastructure.

• Per il riferimento all'API dei task pianificati, 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 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 di Logging 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 al suo interno.

È possibile monitorare lo stato dei task schedulati della ricerca salvata tramite la metrica Stato esecuzione task schedulato. In caso di esecuzione di un task non riuscita o saltata a causa di un'anomalia dell'infrastruttura o di modifica di una risorsa o di una configurazione dipendente, la metrica fornisce i dettagli dell'errore che consente di correggerlo.

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

Ogni task schedulato della ricerca salvata ha il proprio intervallo, come specificato nella relativa pianificazione task. Una metrica viene emessa nella tenancy per ogni esecuzione task pianificata. Passare il cursore sui datapoint nel grafico per visualizzare ulteriori dettagli sul task. Per filtrare i dati delle metriche in base a una delle dimensioni Status, DisplayName o ResourceId, attenersi alla procedura riportata di seguito.

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

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

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

   Nota
   
   

   Per visualizzare grafici e dati tabulari da Metrics Explorer specificando un nome di dimensione e un valore di 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 oppure rinominare il campo esistente utilizzando il comando rename in modo da rimuovere 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 Come rendere performanti le query.

   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 ora visualizzerà solo i datapoint per i quali è stato applicato il filtro.

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

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

È possibile impostare gli 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 mediante questa metrica per valori taskResult specifici.

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

• Requisiti per la composizione delle interrogazioni:

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

  • Nota delle limitazioni per le query delle regole di rilevamento:

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

    • Il comando timestats non può essere seguito dai comandi 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, eventstats, 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 di aggregazione supportate in una query di task pianificato è 1.

  • Utilizzare i valori dei campi link come dimensioni per la contabilizzazione delle metriche:

    Selezionare fino a tre campi dimensione e un parametro numerico da pubblicare nel servizio di monitoraggio. Per indicare quali campi devono essere inviati al monitoraggio, le query devono terminare con:

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

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

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

    • Usare il comando 2 addfields al massimo.
    • Utilizzare fino a 3 funzioni stats.
    • Le istruzioni eval sono necessarie per calcolare i risultati intermedi e finali.

    Query di esempio:

    '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

• Arrivo tardivo dei log:

  Se i task pianificati vengono eseguiti prima dell'arrivo dei log, è possibile che i task pianificati non restituiscano i risultati come previsto. Per evitare la mancanza di tali log nelle attività schedulate 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 verificare il numero di errori di autenticazione e se tra la generazione dei log e il raggiungimento di Oracle Logging Analytics è previsto un ritardo di 3 minuti, il task pianificato non rileverà i log. Si consideri che l'attività pianificata viene eseguita ogni 5 minuti, ad esempio 01:00, 01:05, 01:10 e così via. Se il record di log L1 generato alle 01:04 raggiunge Oracle Logging Analytics alle 01:07. L1 non è stato rilevato nel task pianificato eseguito alle 1:05 perché il log non è arrivato in Oracle Logging Analytics in questo momento. Durante la successiva esecuzione 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. Se i log arrivano in ritardo, la query seguente potrebbe non visualizzare tutti i record dei log:

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

  Per determinare il ritardo nell'arrivo dei log in Oracle Logging Analytics, calcolare la differenza tra l'indicatore orario indicato nel record di log e l'ora di pubblicazione del processore di log. È possibile utilizzare la seguente query di esempio per verificare se esiste 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 eseguito a un intervallo 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 capire come le query sono integrate 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 pianificato. Consulta PostMetricData API nella Documentazione di Oracle Cloud Infrastructure.

    Quando la ricerca salvata può generare più di 50 valori unici per campo, i risultati parziali vengono contabilizzati a causa dei limiti imposti dal servizio di monitoraggio. In questi casi, per visualizzare i risultati top o bottom 50, utilizzare il comando sort.