Bonjour @woodentree ! Ha ha my keyboard doesn't have any of the French things I'd need not to become mad quickly enough lol So, to answer, great the data sources issue is fixed, ole! Then, regarding: - Data hosts This I think is actually working, the thing is that for hosts it behaves a little bit differently and it cannot be lower the higher value between all the sourcetypes idenfitied for the host. The reason is specific to data hosts, which can behave on a per sourcetype, or globally (the global alerting mode) so I had to come with a compromise. The proof in image: Because the default is 3600 secs,  to go bellow this value, this would mean that the sourcetypes themselves go bellow this value, data hosts will take whatever the biggest value. Let me know your thinking, I know this part is a bit tricky. - Loading performance: Gotcha, it's in my plan to work on this and review the UI globally, which will take time, thus there shouldn't have been such an increase so I will investigate! Received for the Git issue, in da back log! Cheers Guilhem   ... View more

Hi @woodentree  Ok, I will check this out deeply and verify, then share some additional things to verify. First you can please upgrade the app to its latest version, especially since you are in testing, there has been many bug fixes since 😉 Then eventually please verify after the update is the behaviior persists and let me know Thank you ... View more

@woodentree  Hum it's actually weird, there should have been a value, remember which which version you're one? Might have been a thing that was fixed later on, the macro define a default value in case the field would null. Can you run: | inputlookup trackme_data_source_monitoring | eval keyid=_key | eval data_override_lagging_class=if(isnull(data_override_lagging_class), "false", data_override_lagging_class) | outputlookup trackme_data_source_monitoring key_field=keyid Then run the tracker and verify? This would fix any null value and set to false (the default) This is safe to do, only this value will get updated and this won't change a thing for other entities. If this fixes the issue you can apply for data hosts too. I will check how it is expected in TrackMe logic too 😉 ... View more

Hi @woodentree  This should just work fine for high priority too, most likely these entities you are looking at (those in high priority) have a the override lagging class field set to true: You can check this out the following way too: For data sources: | inputlookup trackme_data_source_monitoring | eval keyid=_key | search priority="high" AND data_override_lagging_class="true"   And for data hosts: | inputlookup trackme_host_monitoring | eval keyid=_key | search priority="high" AND data_override_lagging_class="true" You could change (bulk change) this the following way: For data sources:   | inputlookup trackme_data_source_monitoring | eval keyid=_key | search priority="high" AND data_override_lagging_class="true" | eval data_override_lagging_class="false" | outputlookup key_field=keyid trackme_data_source_monitoring   And for data hosts:   | inputlookup trackme_host_monitoring | eval keyid=_key | search priority="high" AND data_override_lagging_class="true" | eval data_override_lagging_class="false" | outputlookup key_field=keyid trackme_host_monitoring     Of course if there are some entities that should override lagging classes, you need to either exclude these from the commands above, or check it out within the UI. Then after you run the trackers (or wait a bit) and this should be applied. Let me know Guihem   ... View more

Hi @mark Perfect, so as you can see this is not a false positive, TrackMe is detecting a quality issue in your data, multiple format match means that the sampling detects a given format as shown in the screenshot, in addition events not matching that same format. A proper sourcetype should be matching the same type of events respecting the same type of data under the same format ideally, this is what ensures the data sampling feature. So it's a true positive. If you click on "Show latest sample" this opens a search UI, which shows the events that were sampled and the format that was detected, if you checkout these you will see that there are events not matching the other format. So you can: - Click on the disable button on the right which will disable the sampling feature for this data source if the quality issue cannot be fixed - Potentially you can create a custom model for that data source, if this makes sense and that depends on the data If you disable the feature, then run the Tracker now in the main screen and the data sources will go back to the state it would without the data sampling. Guilhem ... View more

Hi @mark_wymer ! When the data sampling detects an anomaly in a data source, it is very unlikely to be a false positive, at least from a technical point view, this means the component detected an issue in the data quality such as a change in the format, multiple format which was not detected during the discovery etc. Review the documentation: https://trackme.readthedocs.io/en/latest/userguide.html#data-sampling-and-event-formats-recognition The UI shows what the summary of the data sampling state is, and you can access to the latest sample events that were at the root of the issue: Then, either you can fix the issue, or you can create a custom model that matches your data source context with no issues, and you can as well disable the data sampling feature if the quality issue is not something you are able to get fixed. Wen the data sampling status is cleared there is a some delay potentially until the data sources tracker runs again, so either you click on Refresh after you cleared the data sample state, or you click on Run the tracker now, or you wait a bit until these are executed automatically and the status will be cleared. So in short after you cleared the data sampling you would have clicked in the refresh button to have the data source global state refreshed against the new status of the data sampling without closing the current screen, I'll check if both actions can be triggered in the same time when you process the clear state and run sampling action. Thus, do no ignore the data sampling alert, if it triggered it was for a reason and it is likely this will happen again unless you disable the data sampling for it, or fix the issue, or create a model etc The very last version, 1.2.31, includes a new component called Smart Status which give an extended understanding of the root cause and runs the models automatically to provide an answer: https://trackme.readthedocs.io/en/latest/userguide.html#smart-status Let me know if this is clear and if you have any question, always more than happy to have users inputs. Guilhem ... View more

Hi @willadams  By defaut, the reports handling and maintaining the update of these information in the KVstore collections are enabed and scheduled, you may have had something disabling it somehow during your deployment, or someone else did. Let me know if you face any further issue. Guilhem ... View more

@rbolande  TrackMe 1.2.28 is now out in Splunk Base, this version supports officially monitoring lookups, CSV or KVstore based, locally or remotely via REST: https://trackme.readthedocs.io/en/latest/userguide.html#elastic-source-example-4-creation If any question or issues, let us know 😉 Guilhem ... View more

Hi @rbolande  Thanks and no pb at all. I am fully convinced by the use case and TrackMe is perfectly in line for the job 😉 Lookup tracking will be fully taken in charge in the upcoming 1.2.28 version: https://trackme.readthedocs.io/en/testing/userguide.html#elastic-source-example-3-tracking-lookups-update https://trackme.readthedocs.io/en/testing/userguide.html#elastic-source-example-3-creation Which allows exactly what you mentioned, monitoring that the lookup was last updated in a given time period, and as well tracking the number of records via the outliers detection. In addition, TrackMe 1.2.28 will allow as well tracking lookups remotely, which means monitoring lookups against remote Splunk search head(s) using the rest command, that is being able to track lookups that are available from the search head(s) hosting the TrackMe app. Dev and qualification is on processing and the release will be published shortly. Let me know if you have any question. Guilhem ... View more

HI @rbolande  Thank you very much 😉 I am very glad you enjoy it! (well common truely TrackMe is stunning lol) I am interested in this use case, these were one of the things I was thinking about underneath the Elastic sources. I believe indeed the from approach with Elastic Sources would comply with the requirements, I haven't much the chance to document it and what would be the requirements, however I believe something like this would be a good start: In this example, the lookup has an _time field, there are some concepts which of course are not relevant for a lookup like ingestion level metrics, however if the lookup has an _time field then it is possible to monitor the "event lag" naturally: With a few evolutions, I could design TrackMe to fully address the use case, if you wanna tell me more about yours feel free to do so, otherwise I will start to look at it. It is a very good case, I see so often customers not having the knowledge that the lookups were not updated, this is a definitively a job for TrackMe. Guilhem ... View more

Hi @GOB_Bluth  Please apologise, I haven't noticed your question on TrackMe earlier.  Have you made any progress?  TrackMe is pretty straightforward, so it is unlikely that it cannot proceed to the discovery of the data sources, hosts and other types of obects being tracked. I will think in writting a trouble shooting doc in the official documentation. At the root of TrackMe, there are "trackers", which are scheduled reports designed to be tackling the data discovery and the maintenance of the various KVstore collections. Focussing on data sources, you would first look at the reports named: TrackMe - Data sources availability short term tracker The first part of the search would allow to see easily the data being found: | savedsearch "TrackMe - Data sources abstract root tracker" You haven't shared much details such as screenshots, please do so or contact me on Slack if you are still blocked. Guilhem ... View more

Hi @woodentree  TrackMe 1.2.27 was published today and allows you to create builtin lagging classes based on the priority for data sources: https://trackme.readthedocs.io/en/latest/userguide.html#lagging-classes Let me know if you have any question. Kind regards, Guilhem   ... View more

Hi @saikiran334  I am afraid that even after very carefully reading your question, I am not getting it. "on this new Azure SH by syncing with OnPrem SH" no idea what you mean here. You can install TrackMe in any search head, standalone or SHC, that makes sense for you, if the search head can search in the indexers you need, then TrackMe will be able to access to it. Guilhem ... View more

@david_peacock  The following is an example of a rest call data sent: { "@type": "MessageCard", "@context": "http://schema.org/extensions", "themeColor": "0076D7", "summary": "MS teams addon testing please ignore", "sections": [ { "activityTitle": "MS teams addon testing please ignore", "activitySubtitle": "", "activityImage": "https://www.google.com/peralert", "facts": [ { "name": "apple", "value": "This is an apple" }, { "name": "bad", "value": "\\\\n" }, { "name": "kiwi", "value": "This is a kiwi" }, { "name": "mango", "value": "And I likes mango too" }, { "name": "message", "value": "Test!" }, { "name": "pears", "value": "This is a pear" }, { "name": "ziziphus", "value": " No idea found in the Internet and start by Z!" } ], "markdown": false } ], "potentialAction": [ { "@type": "OpenUri", "name": "Open first action", "targets": [ { "os": "default", "uri": "https://www.splunk.com" } ] }, { "@type": "OpenUri", "name": "Open Second action", "targets": [ { "os": "default", "uri": "https://www.google.co.uk" } ] }, { "@type": "HttpPOST", "name": "test ack", "target": "https://www.google.co.uk/post" } ] } ... View more

@david_peacock  Right, odd, there seem to be thing in your context. Please enable the DEBUG mode in the logging level of the addon, then if you get the alert to trigger, you will see in the logs the JSON data that is being sent to the API then we can compare. I shall try to have a look when possible, however as far as I knew it was always worked perfectly fine unless MS changed a thing but that'd be surprising. ... View more

Hi @david_peacock  I believe this is linked to your fields being multi-value fields. If you end up your search for example with:   | foreach API_APPLICATION, API_ENDPOINT [ eval <<FIELD>> = mvjoin('<<FIELD>>', "|") ]   This would ensure that if you have a multivalue field, these will be managed as a pipe separated list of values instead. Secondly, for the action button the token may not be resulting in any value which is why the Addon strips it automatically, I would advise you to try to provide a static URI to a dashboard or a report instead to verify. Let me know Guilhem ... View more

@mark_wymer  In true every index you declared on the indexers should be declared in the same way in all the search heads accessing these same indexers, this is a configuration good practice for different reasons such as the index name auto completion, or this use case you encountered. The good deployment config practice we recommend you to use the Professional Services base config apps: Base Apps: https://drive.google.com/open?id=107qWrfsv17j5bLxc21ymTagjtHG0AobF Cluster Apps: https://drive.google.com/open?id=10aVQXjbgQC99b9InTvncrLFWUrXci3gz In your deployment, on the search head you want: - The same volumes defined than you have in your indexer cluster - Which allows you to push the exact same copy of indexes.conf you deploy to the indexers My best advise is to look at what Splunkenizer does: https://github.com/splunkenizer/Splunkenizer (you can spawn a virtual env and analyse for instance) Splunkenizer generates a 100% perfect good practice compliant Splunk env. (and is in between such a wonderful thing!) Last but not least, trackme itself includes a default/indexes.conf, since some years this is not something recommended (from the app publication point of view), however this is required for TrackMe because there are various usage of collect and mcollect commands in different reports, which would lead appinspect to fail if the indexes are not part of the app, plus some more serious issues like you had. So technically you should have had the indexes defined in the search head too Guilhem ... View more

Hi @jonqkuldeskisecurity To reply: version 1.210 will surely be published shortly, within a week from now the current version is 1.2.9 and is vetted for Splunk Cloud, compatibility starts with 7.2.x Dependencies besides the viz addon are with the machine learning toolkit which itself depends on the Python scientific package The current release of the ML toolkit and Python scientific package are with SPLUNK 8 only, but there are previous versions compatible with your stack version if you ask the ML toolkit deployment, SPLUNK Cloud services will deploy the latest versions compatible with your stack, which will be upgraded too when your stack would be upgraded finally yes the next version will be compatible with 7.2.x, the reason why there is this minimal Splunk version now is that the app uses mcollect which requires this version of Splunk. Guilhem ... View more

Hi @jonqkuldeskisecurity ! Thank you 😉 I understand you are talking about the builtin alert named "TrackMe - Alert on data host availability" and the order of the fields in the results. You can effectively modify the alert up to your needs to include the fields in the order you prefer, therefore take note that Splunk will automatically achieve a copy of the alert provided by the app code (in the default/savedsearches.conf) to a local copy which will contain your customisation. This is perfectly fine but any change in the default code will not be reflected anymore and you will have to manage it on your own. However, in the next upcoming release, version 1.2.11, I will include a macro which defines the order of the fields. Macros are better to be customised in the meaning that a customisation will impact a very specific part of the alert, rather than its full definition. Let me me know if this does not make sense, and thank you for using TrackMe ! Guilhem ... View more

@amksa Please upgrade to the version 1.0.8 of the add-on, that was published on Splunk Base. This version will allow you to define the Components field in the custom field section, without its section to be managed as characters to be protected. (the reason why it failed when you attempted to do so.) Assuming your JIRA admins allowed the field to be defined in the screens, and you input values format accepted by your JIRA, this will fix your issue. Let me know if any further issue. Guilhem ... View more

So @amksa I could re-reproduce this, by default the field "Components" is an optional field in JIRA, not required. But certainly your JIRA admin has defined this field to be mandatory, which is why the creation is failing with the following message: Components REQUIRED [Autocomplete Renderer }, HTTP Error=400, content={"errorMessages":[],"errors":{"components":"Components is required."}}" I am checking if how this can be managed. Guilhem ... View more

Hi @amksa Hum right, I will need to perform some verifications, can you confirm that the message: HTTP Error=400, content={"errorMessages":[],"errors":{"components":"Components is required."}} Is returned by JIRA ? This might indicate effectively a required field maybe for the tasks or in respect with your JIRA fields configuration. The custom field section is meant to be used for proper custom fields only, this shouldn't apply for non custom fields. Guilhem ... View more