SOLVED
Home

Reliably trigger alerts for Log Analytics log entries

%3CLINGO-SUB%20id%3D%22lingo-sub-309610%22%20slang%3D%22en-US%22%3EReliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-309610%22%20slang%3D%22en-US%22%3E%3CP%3EMSDN%20documentation%20at%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Falert-log-troubleshoot%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Falert-log-troubleshoot%3C%2FA%3E%20states%3A%26nbsp%3B%3CSPAN%3E%22To%20mitigate%20data%20ingestion%20delay%2C%20the%20system%20waits%20and%20retries%20the%20alert%20query%20multiple%20times%20if%20it%20finds%20the%20needed%20data%20is%20not%20yet%20ingested%22.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EWe%20have%20an%20issue%20with%20triggering%20alerts%20and%20the%20issue%20suggests%20that%20described%20behavior%20is%20not%20very%20reliable%20as%20a%20lot%20of%20our%20alerts%20aren't%20fired.%20To%20be%20more%20precise%20-%20we%20ingress%20logs%20from%20Data%20Factory%20V2%20into%20Log%20Analytics%20and%20watch%20for%20log%20entries%20with%20Level%20%3D%3D%20%22Error%22%2C%20based%20on%20number%20of%20results%20greater%20that%200%20(Period%20%3D%20Frequency%20%3D%2030%20minutes).%20We%20expect%20that%20in%20case%20a%20log%20entry%20with%20Level%20%3D%3D%20%22Error%22%20is%20generated%20by%20Data%20Factory%20and%20ingested%20into%20Log%20Analytics%20we%20shall%20receive%20an%20alert%2C%20but%20very%20often%20we%20don't.%20We%20tried%20to%20change%20Period%20to%20larger%20values%20(30%20minutes)%20leaving%20Frequency%20at%2015%20but%20in%20this%20case%20there%20is%20a%20big%20chance%20to%20receive%20duplicated%20alerts%20which%20also%20is%20not%20good.%20Are%20there%20any%20recommended%20and%20reliable%20Period%2FFrequency%2FQuery%20configuration%20strategy%20that%20guarantees%20no%20alerts%20are%20missing%20and%20also%20does%20not%20produce%20duplicated%20alerts%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-309610%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20Log%20Analytics%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-320265%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-320265%22%20slang%3D%22en-US%22%3E%3CP%3EStanislav%2C%20thank%20you%20very%20much!%20I%20just%20tried%20that%20new%20API%20and%20it%20works%20-%20emails%20are%20properly%20sent%2C%20action%20group%20does%20not%20disapper.%20Finally!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319450%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319450%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%0A%3CP%3EThe%20new%20API%20is%20discussed%20here%3A%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2FAzure-Log-Analytics%2FLog-Analytics-ARM-REST-API-specification-update%2Fm-p%2F306978%23M1166%22%20target%3D%22_blank%22%3Ehttps%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2FAzure-Log-Analytics%2FLog-Analytics-ARM-REST-API-specification-update%2Fm-p%2F306978%23M1166%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20haven't%20published%20examples%20on%20my%20blog%20as%20I%20try%20to%20avoid%20publishing%20things%20before%20they%20are%20are%20announced%20officially%20but%20I%20have%20been%20using%20the%20API%20for%20several%20weeks%20now.%20It%20had%20some%20bugs%20that%20I%20hope%20are%20fixed%2For%20will%20be%20fixed%20before%20official%20release.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319348%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319348%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20weird%20thing%20is%20that%20action%20group%20seems%20to%20be%20attached%20when%20I%20create%20alert%20via%20ARM.%20At%20least%20I%20can%20see%20it%20on%20Monitor%20-%26gt%3B%20Alerts%20-%26gt%3B%20%22Manage%20alert%20rules%22%20page%20(image%201%20in%20attached%20screenshot).%26nbsp%3BAction%20group%20is%20only%20missing%20when%20looking%20at%20alert%20rule%20via%20link%20from%20triggered%20alert%20instance%20(%22Alert%20rule%22%20in%20the%20%22Essentials%22%20section%2C%20image%202%20in%20attached%20screenshot).%3C%2FP%3E%3CP%3EA%20tried%20to%20get%20alert%20action%20JSON%20using%20REST%20API%26nbsp%3B-%26nbsp%3Breference%20to%20action%20group%20it%20is%20there.%20After%20re-saving%20an%20alert%20from%20the%20Portal%20or%20by%20get%2Fput%20REST%20API%20calls%20nothing%20changes%20in%20action%20JSON%20(except%20etag)%2C%20but%20somehow%26nbsp%3Bsuch%20re-save%26nbsp%3Bfixes%20the%20issue%2C%20so%20something%20internal%20is%20definitely%20changed.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHere%20goes%20sample%20request%20I%20used%20to%20get%20alert%20action%3A%3C%2FP%3E%3CPRE%3E%24actionUrl%20%3D%20%22%2Fsubscriptions%2F%7Bsubscription%20id%7D%2FresourceGroups%2F%7Bres%20group%20name%7D%2Fproviders%2FMicrosoft.OperationalInsights%2Fworkspaces%2Fcdm1drepomsf01%2FsavedSearches%2Fsaved_search60eee2d2dc0b42dd87cd0a06b1c3f335%2Fschedules%2Fschedule_60eee2d2dc0b42dd87cd0a06b1c3f335%2Factions%2Faction_60eee2d2dc0b42dd87cd0a06b1c3f335%3Fapi-version%3D2015-03-20%22%3CBR%20%2F%3E%24jsonStr%20%3D%20armclient%20get%20%24actionUrl%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20here%20is%20what%20I%20used%20to%20re-save%20alert%20action%20via%20REST%20API%3A%3C%2FP%3E%3CPRE%3E%24json%20%3D%20%24jsonStr%20%7C%20ConvertFrom-Json%3CBR%20%2F%3E%24json2%20%3D%20%40%7B%3CBR%20%2F%3E%26nbsp%3B%20etag%3D%24json.etag%3CBR%20%2F%3E%26nbsp%3B%20properties%3D%24json.properties%3CBR%20%2F%3E%7D%3CBR%20%2F%3E%24json2%20%3D%20%24json2%20%7C%20ConvertTo-Json%20-Depth%203%3CBR%20%2F%3E%24json2%20%7C%20armclient%20put%20%24actionUrl%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAPI%26nbsp%3Bsamples%20may%20be%20found%20here%3A%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Fapi-alerts%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Fapi-alerts%3C%2FA%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYou've%20mentioned%20that%20link%20points%20to%20an%20old%20API%20(it%20has%20%22(Preview)%22%20in%20title).%20Do%20you%20have%20a%20link%20to%20a%20new%20ARM%20API%20for%20Log%20Analytics%20alerts%20creation%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319315%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319315%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20the%20action%20group%20is%20not%20attached%20to%20the%20alert%20via%20ARM%20that%20means%20the%20action%20group%20was%20not%20referenced%20correctly.%20You%20have%20to%20make%20sure%20that%20the%20resource%20id%20of%20the%20action%20group%20is%20correct.%20I%20think%20there%20was%20also%20some%20bug%20that%20I've%20reported%20some%20time%20ago%20on%20the%20old%20Log%20Analytics%20alerts%20API%20where%20if%20the%20action%20group%20name%20contains%20white%20spaces%20the%20API%20cannot%20find%20the%20Action%20Group%20resource.%20The%20API%20also%20does%20not%20verifies%20if%20the%20action%20group%20exists%20so%20if%20it%20does%20not%20exist%20it%20will%20create%20the%20alert%20anyway.%20Workaround%20for%20that%20bug%20was%20to%20use%20name%20without%20white%20spaces%20so%20the%20resource%20ID%20can%20be%20correct%20or%20or%20to%20encode%20the%20name%20of%20the%20action%20group%20resource%20when%20you%20construct%20the%20resource%20id.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20see%20that%20you%20provide%20link%20to%20the%20old%20API%20so%20probably%20that%20bug%20still%20exists.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319286%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319286%22%20slang%3D%22en-US%22%3E%3CP%3EStanislav%2C%20thank%20you%20a%20lot%20for%20your%20replies.%20Just%20for%20completeness%20I'd%20like%20to%20provide%20an%20update%20on%20my%20issue.%20After%20getting%20access%20to%20Alerts%20on%20a%20Subscription%20level%20we've%20realized%20that%20all%20alerts%20are%20actually%20triggered%2C%20so%20there%20are%26nbsp%3Bno%20bugs%20in%20the%20documentation%2C%20everything%20works%20fine%20even%20with%205%20minutes%20Interval.%3C%2FP%3E%3CP%3EThe%20actual%20but%20happened%20to%20be%20that%20triggered%20alerts%20have%20theit%20Action%20Group%20property%20empty%2C%20thats%20why%26nbsp%3Bemails%20are%20not%20sent.%20%3CSPAN%3EAction%20Group%20is%20not%20empty%20when%20viewing%20alert%20rules%20from%20Monitor%20-%26gt%3B%20Alerts%20-%26gt%3B%20%22Manage%20alert%20rules%22%20page%2C%20but%20it%20is%20empty%20when%26nbsp%3Bnavigating%20to%20alert%20rule%20via%20link%20inside%26nbsp%3Btriggered%20alert%20instance.%20This%20definitely%20looks%20strange%2C%20we're%20already%20working%20on%20this%20issue%20with%20MS%20support.%20The%20initial%26nbsp%3Binvestigation%20showed%20that%20problem%20might%20be%20with%20deploying%20Log%20Analytics%20alerts%20using%20ARM%20template.%20Whn%20we%20manuall%20create%20alert%20rule%20from%20the%20Portal%20all%20is%20fine%2C%20but%20when%20they%20are%20created%20with%20the%20help%20of%20ARM%20-%20Action%20Goup%20on%20triggered%20alerts%20is%20empty%20for%20some%20reason.%20The%26nbsp%3Bcurrently%20found%20workarounds%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E1.%20After%20ARM%20deployment%20go%20to%20the%20Portal%20and%20manually%20re-save%20alert%20rules.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E2.%26nbsp%3BAfter%20ARM%26nbsp%3Bdeployment%26nbsp%3Buse%20REST%20API%20to%20get%20and%20set%20alert%20actions%20(this%20is%20also%20just%20%22re-save%22%20with%20no%20modification).%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EThe%20ARM%20is%20based%20on%20examples%20from%20page%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Finsights%2Fsolutions-resources-searches-alerts%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Finsights%2Fsolutions-resources-searches-alerts%3C%2FA%3E.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-310323%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-310323%22%20slang%3D%22en-US%22%3E%3CP%3EI%20think%20the%20alert%20instances%20itself%20are%20subscription%20level%20resource%20so%20you%20will%20need%20some%20access%20at%20subscription%20level%20not%20resource%20group.%20You%20do%20not%20need%20necessary%20to%20be%20Contributor%20at%20subscription%20level%2C%20for%20example%20you%20can%20be%20Monitoring%20contributor.%20You%20can%20also%20opt-in%20at%20creating%20your%20own%20custom%20role%20and%20have%20access%20to%20resources%20like%20Microsoft.AlertsManagement%2Falerts%2F%20and%20Microsoft.AlertsManagement%2FalertsSummary%2F%20at%20subscription%20level.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-310320%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-310320%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20for%20reply.%20I%20have%20one%20more%20question%20regarding%26nbsp%3B%22%3CSPAN%3EThe%20only%20reason%20why%20you%20are%20not%20seeing%20the%20alerts%20in%20Azure%20Monitor%20if%20you%20haven't%20selected%20the%20subscription%20of%20the%20where%20the%20Log%20Analytics%20wokrspace%20is%20located%3C%2FSPAN%3E%22.%20I%20have%20only%20one%20subscription%20to%20choose%20from%2C%20so%20there%20is%20no%20chance%20I%20can%20select%20the%20wrong%20one.%20Additional%20investigation%20revealed%20that%20my%20%3CSPAN%3Ecolleague%20can%20see%20alerts%2C%20but%20he%20is%20an%20Owner%20of%20the%20Subscription%2C%20while%20I%20am%20a%20Contributor%20of%20Resource%20Group%20where%20alerts%20are%20created.%20I%20can%20create%20alerts%2C%20change%20them%2C%20but%20cannot%20see%20which%20alerts%20were%20triggered.%20Unfortunately%20I%20cannot%20be%20granted%20any%20rights%20on%20global%20Subscription%20level%2C%20are%20there%20any%20way%20to%20configure%20a%20per%20Resource%20Group%20access%20so%20I'll%20be%20able%20to%20see%20alerts%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-309844%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-309844%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%0A%3CP%3EThe%20first%20thing%20you%20should%20do%20is%20to%20never%20use%20search%20operator%20in%20alerts%20or%20any%20kind%20of%20saved%20queries.%20Search%20operator%20is%20usually%20used%20on%20discovering%20data%20initially%20but%20once%20you%20know%20where%20your%20data%20is%20you%20should%20stop%20using%20it.%20This%20is%20also%20described%20here%3A%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fazure.microsoft.com%2Fen-us%2Fblog%2Fbest-practices-for-queries-used-in-log-alerts-rules%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fazure.microsoft.com%2Fen-us%2Fblog%2Fbest-practices-for-queries-used-in-log-alerts-rules%2F%3C%2FA%3E%3C%2FP%3E%0A%3CP%3EI%20am%20assuming%20that%20for%20Data%20factory%20you%20use%20diagnostic%20logs%20which%20are%20send%20to%20Log%20Analytics.%20In%20that%20case%20your%20data%20is%20in%20%3CSPAN%20style%3D%22color%3A%20%23000000%3B%22%3EAzureDiagnostics%3C%2FSPAN%3E%20table%20so%20your%20query%20should%20look%20like%3A%3C%2FP%3E%0A%3CPRE%3EAzureDiagnostics%0A%7C%20where%20ResourceProvider%20%3D%3D%20%22MICROSOFT.DATAFACTORY%22%20and%20(Level%20%3D%3D%20%22Error%22%20or%20status_s%20%3D%3D%20%22Failed%22)%0A%7C%20order%20by%20TimeGenerate%3C%2FPRE%3E%0A%3CP%3EYou%20can%20also%20skip%20%7C%20order%20by%20TimeGenerated%20when%20you%20use%20it%20in%20alert%20as%20it%20does%20not%20have%20any%20affect%20there.%3C%2FP%3E%0A%3CP%3EHere%20is%20some%20information%20how%20ingestion%20time%20can%20be%20checked%20although%20I%20do%20not%20think%20that%20is%20the%20problem%20for%20you%3A%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Fdata-ingestion-time%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fazure-monitor%2Fplatform%2Fdata-ingestion-time%3C%2FA%3E%3C%2FP%3E%0A%3CP%3EKeep%20in%20mind%20that%20in%20e-mail%20only%2010%20results%20will%20be%20added%20to%20the%20e-mail%20but%20if%20you%20go%20to%20the%20link%20of%20the%20alert%20query%20results%20you%20will%20see%20all%20the%20results.%3C%2FP%3E%0A%3CP%3EThe%20only%20reason%20why%20you%20are%20not%20seeing%20the%20alerts%20in%20Azure%20Monitor%20if%20you%20haven't%20selected%20the%20subscription%20of%20the%20where%20the%20Log%20Analytics%20wokrspace%20is%20located.%20Azure%20Monitor%20can%20display%20alerts%20from%205%20subscription%20maximum.%3C%2FP%3E%0A%3CP%3EI%20usually%20use%20metric%20measurement%20based%20alerts%20rather%20number%20of%20results%20type%20as%20that%20way%20I%20can%20get%20alert%20per%20instance.%20I%20have%20a%20small%20blog%20describing%20that%20scenario%20here%3A%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fcloudadministrator.net%2F2018%2F03%2F16%2Fusing-custom-log-search-alerts-based-on-metric-measurement-for-event-based-logs%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fcloudadministrator.net%2F2018%2F03%2F16%2Fusing-custom-log-search-alerts-based-on-metric-measurement-for-event-based-logs%2F%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-309829%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-309829%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20exact%20query%20is%3A%3C%2FP%3E%3CP%3Esearch%20*%3CBR%20%2F%3E%7C%20where%20ResourceProvider%20%3D%3D%20%22MICROSOFT.DATAFACTORY%22%20and%20(Level%20%3D%3D%20%22Error%22%20or%20status_s%20%3D%3D%20%22Failed%22)%3CBR%20%2F%3E%7C%20order%20by%20TimeGenerated%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EQuery%20is%20running%20over%20Log%20Analytics%20to%20which%20Data%20Factory%20V2%20writes%20them%20(with%20several%20minutes%20delay%2C%20but%20it%20is%20hard%20to%20tell%20the%20exact%20numbers).%3C%2FP%3E%3CP%3EWhen%20I%20set%20Period%20%3D%20Frequency%20%3D%205%20minutes%20then%20more%20than%2050%25%20of%20alert%20emails%20are%20missing%2C%20for%20Period%20%3D%20Frequency%20%3D%2015%20almost%20all%20logs%20relult%20in%20alert%20email%2C%20but%20not%20100%25%20all.%3C%2FP%3E%3CP%3EExcept%20described%20issue%20there%20is%20a%20more%20severe%20issue%2C%20which%20may%20be%20related%20to%20the%20described%20one.%20When%20I%20navigate%20to%20Monitor%20-%26gt%3B%20Alerts%20I%20always%20see%20%22%3CSPAN%3EAll%20is%20good!%20You%20have%20no%20alerts.%3C%2FSPAN%3E%22%20message%20which%20is%20really%20strange.%20I%20expect%20to%20see%20statistics%20about%20triggered%20alerts.%3C%2FP%3E%3CP%3EBecause%20of%20this%20%22%3CSPAN%3EYou%20have%20no%20alerts.%3C%2FSPAN%3E%22%20message%26nbsp%3Bit%20is%20hard%20to%20be%20sure%20that%20the%20issue%20is%20with%20alerts%20but%20not%20with%20emails%20(configured%20via%20Action%20Group).%20Our%20assumption%20was%20%22there%20might%20be%20an%20issue%20with%20emails%20delivering%2C%20e.g.%20because%20of%20spam%20filters%22%20but%20this%20assumption%20was%20dismissed%20after%20we%20configured%20Azure%20Function%20action%20type%20-%20azure%20functions%20are%20not%20invoked%26nbsp%3Bwhen%20emails%20are%20missing%20and%20are%20invoked%20when%20emails%20are%20delivered%2C%20so%20at%20least%20there%20is%20consistency%20with%20emails%20and%20Azure%20Function%20action%20types.%3C%2FP%3E%3CP%3EWhat%20may%20be%20the%20reason%20of%20%22%3CSPAN%3EAll%20is%20good!%20You%20have%20no%20alerts.%3C%2FSPAN%3E%22%20message%20is%20always%20present%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-309722%22%20slang%3D%22en-US%22%3ERe%3A%20Reliably%20trigger%20alerts%20for%20Log%20Analytics%20log%20entries%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-309722%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%0A%3CP%3EMy%20testing%20shows%20that%20when%20there%20is%20delay%20of%20data%20ingestion%20the%20alert%20is%20still%20fired%20up.%20Of%20course%20the%20alert%20is%20inheriting%20that%20delay%20but%20I%20haven't%20found%20missing%20alerts%20so%20far.%20May%20be%20you%20can%20share%20more%20about%20the%20experience%20you%20have%3A%20what%20kind%20of%20data%20source%20you%20use%3F%20when%20you%20have%20missing%20alerts%20have%20you%20compared%20ingested%20time%20with%20Time%20Generated%20for%20those%20events%3F%20What%20is%20your%20exact%20query%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Roman_Turovskyy
Occasional Contributor

MSDN documentation at https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alert-log-troubleshoot states: "To mitigate data ingestion delay, the system waits and retries the alert query multiple times if it finds the needed data is not yet ingested".

We have an issue with triggering alerts and the issue suggests that described behavior is not very reliable as a lot of our alerts aren't fired. To be more precise - we ingress logs from Data Factory V2 into Log Analytics and watch for log entries with Level == "Error", based on number of results greater that 0 (Period = Frequency = 30 minutes). We expect that in case a log entry with Level == "Error" is generated by Data Factory and ingested into Log Analytics we shall receive an alert, but very often we don't. We tried to change Period to larger values (30 minutes) leaving Frequency at 15 but in this case there is a big chance to receive duplicated alerts which also is not good. Are there any recommended and reliable Period/Frequency/Query configuration strategy that guarantees no alerts are missing and also does not produce duplicated alerts?

10 Replies

Hi,

My testing shows that when there is delay of data ingestion the alert is still fired up. Of course the alert is inheriting that delay but I haven't found missing alerts so far. May be you can share more about the experience you have: what kind of data source you use? when you have missing alerts have you compared ingested time with Time Generated for those events? What is your exact query?

The exact query is:

search *
| where ResourceProvider == "MICROSOFT.DATAFACTORY" and (Level == "Error" or status_s == "Failed")
| order by TimeGenerated

 

Query is running over Log Analytics to which Data Factory V2 writes them (with several minutes delay, but it is hard to tell the exact numbers).

When I set Period = Frequency = 5 minutes then more than 50% of alert emails are missing, for Period = Frequency = 15 almost all logs relult in alert email, but not 100% all.

Except described issue there is a more severe issue, which may be related to the described one. When I navigate to Monitor -> Alerts I always see "All is good! You have no alerts." message which is really strange. I expect to see statistics about triggered alerts.

Because of this "You have no alerts." message it is hard to be sure that the issue is with alerts but not with emails (configured via Action Group). Our assumption was "there might be an issue with emails delivering, e.g. because of spam filters" but this assumption was dismissed after we configured Azure Function action type - azure functions are not invoked when emails are missing and are invoked when emails are delivered, so at least there is consistency with emails and Azure Function action types.

What may be the reason of "All is good! You have no alerts." message is always present?

Hi,

The first thing you should do is to never use search operator in alerts or any kind of saved queries. Search operator is usually used on discovering data initially but once you know where your data is you should stop using it. This is also described here:

https://azure.microsoft.com/en-us/blog/best-practices-for-queries-used-in-log-alerts-rules/

I am assuming that for Data factory you use diagnostic logs which are send to Log Analytics. In that case your data is in AzureDiagnostics table so your query should look like:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DATAFACTORY" and (Level == "Error" or status_s == "Failed")
| order by TimeGenerate

You can also skip | order by TimeGenerated when you use it in alert as it does not have any affect there.

Here is some information how ingestion time can be checked although I do not think that is the problem for you:

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-ingestion-time

Keep in mind that in e-mail only 10 results will be added to the e-mail but if you go to the link of the alert query results you will see all the results.

The only reason why you are not seeing the alerts in Azure Monitor if you haven't selected the subscription of the where the Log Analytics wokrspace is located. Azure Monitor can display alerts from 5 subscription maximum.

I usually use metric measurement based alerts rather number of results type as that way I can get alert per instance. I have a small blog describing that scenario here:

https://cloudadministrator.net/2018/03/16/using-custom-log-search-alerts-based-on-metric-measurement...

Thanks for reply. I have one more question regarding "The only reason why you are not seeing the alerts in Azure Monitor if you haven't selected the subscription of the where the Log Analytics wokrspace is located". I have only one subscription to choose from, so there is no chance I can select the wrong one. Additional investigation revealed that my colleague can see alerts, but he is an Owner of the Subscription, while I am a Contributor of Resource Group where alerts are created. I can create alerts, change them, but cannot see which alerts were triggered. Unfortunately I cannot be granted any rights on global Subscription level, are there any way to configure a per Resource Group access so I'll be able to see alerts?

I think the alert instances itself are subscription level resource so you will need some access at subscription level not resource group. You do not need necessary to be Contributor at subscription level, for example you can be Monitoring contributor. You can also opt-in at creating your own custom role and have access to resources like Microsoft.AlertsManagement/alerts/ and Microsoft.AlertsManagement/alertsSummary/ at subscription level.

Stanislav, thank you a lot for your replies. Just for completeness I'd like to provide an update on my issue. After getting access to Alerts on a Subscription level we've realized that all alerts are actually triggered, so there are no bugs in the documentation, everything works fine even with 5 minutes Interval.

The actual but happened to be that triggered alerts have theit Action Group property empty, thats why emails are not sent. Action Group is not empty when viewing alert rules from Monitor -> Alerts -> "Manage alert rules" page, but it is empty when navigating to alert rule via link inside triggered alert instance. This definitely looks strange, we're already working on this issue with MS support. The initial investigation showed that problem might be with deploying Log Analytics alerts using ARM template. Whn we manuall create alert rule from the Portal all is fine, but when they are created with the help of ARM - Action Goup on triggered alerts is empty for some reason. The currently found workarounds:

1. After ARM deployment go to the Portal and manually re-save alert rules.

2. After ARM deployment use REST API to get and set alert actions (this is also just "re-save" with no modification).

The ARM is based on examples from page https://docs.microsoft.com/en-us/azure/azure-monitor/insights/solutions-resources-searches-alerts.

If the action group is not attached to the alert via ARM that means the action group was not referenced correctly. You have to make sure that the resource id of the action group is correct. I think there was also some bug that I've reported some time ago on the old Log Analytics alerts API where if the action group name contains white spaces the API cannot find the Action Group resource. The API also does not verifies if the action group exists so if it does not exist it will create the alert anyway. Workaround for that bug was to use name without white spaces so the resource ID can be correct or or to encode the name of the action group resource when you construct the resource id.

 

I see that you provide link to the old API so probably that bug still exists.

The weird thing is that action group seems to be attached when I create alert via ARM. At least I can see it on Monitor -> Alerts -> "Manage alert rules" page (image 1 in attached screenshot). Action group is only missing when looking at alert rule via link from triggered alert instance ("Alert rule" in the "Essentials" section, image 2 in attached screenshot).

A tried to get alert action JSON using REST API - reference to action group it is there. After re-saving an alert from the Portal or by get/put REST API calls nothing changes in action JSON (except etag), but somehow such re-save fixes the issue, so something internal is definitely changed.

 

Here goes sample request I used to get alert action:

$actionUrl = "/subscriptions/{subscription id}/resourceGroups/{res group name}/providers/Microsoft.OperationalInsights/workspaces/cdm1drepomsf01/savedSearches/saved_search60eee2d2dc0b42dd87cd0a06b1c3f335/schedules/schedule_60eee2d2dc0b42dd87cd0a06b1c3f335/actions/action_60eee2d2dc0b42dd87cd0a06b1c3f335?api-version=2015-03-20"
$jsonStr = armclient get $actionUrl

 

And here is what I used to re-save alert action via REST API:

$json = $jsonStr | ConvertFrom-Json
$json2 = @{
  etag=$json.etag
  properties=$json.properties
}
$json2 = $json2 | ConvertTo-Json -Depth 3
$json2 | armclient put $actionUrl

 

API samples may be found here: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/api-alerts.

 

You've mentioned that link points to an old API (it has "(Preview)" in title). Do you have a link to a new ARM API for Log Analytics alerts creation?

Solution

Hi,

The new API is discussed here:

https://techcommunity.microsoft.com/t5/Azure-Log-Analytics/Log-Analytics-ARM-REST-API-specification-...

 

I haven't published examples on my blog as I try to avoid publishing things before they are are announced officially but I have been using the API for several weeks now. It had some bugs that I hope are fixed/or will be fixed before official release.

Stanislav, thank you very much! I just tried that new API and it works - emails are properly sent, action group does not disapper. Finally!