Can we ignore timestamps for some of the inputs in the SCOM TA?

[maciep]

We are testing the SCOM TA and noticed that the inputs are using the timestamps of objects as the timestamp in Splunk. And I believe those timestamps are being treated kinda like a "rising column" within the script.

I think that's a nice feature for some scom objects, but not something we want for every type of scom object. For example, the monitors. I'd rather just get a dump of all of the monitors each time the input script kicks off. I don't want to only ingest new/modified monitors since the last run time. As it is now, to see all monitors in our environment, we have to run the search against the past 10 months...and eventually that might be all time...and for rarely modified monitors, they'll just roll to frozen eventually.

Is that possible or am I missing something else? I do see in the script where the g_timestamp dictionary item is created. Can I just comment out items in that list? Or will that break other things? Or is there a more supported way to do what i want? I think I read most of the documentation, but this could still be a rtfm scenario.

Thanks!

[maciep]

I ended making a fewchanges. I'm not sure if anyone else is/will want to do something like this, but thought I'd share in case.

First, I did comment out the g_timestamp dictionary items for some of the cmdlets. I don't want to ingest only new items. I want to ingest all items each run.

$g_timestamp = @{
    # events
    "Get-SCOMAlert"      = "TimeAdded"
    'Get-SCOMEvent'      = "TimeAdded"
    #"Get-SCOMMonitor"    = "LastModified"
    "Get-SCOMDiagnostic" = "LastModified"
    "Get-SCOMTask"       = "LastModified"
    "Get-SCOMRecovery"   = "LastModified"
    "Get-SCOMDiscovery"  = "LastModified"
    #"Get-SCOMOverride"   = "LastModified"
    #"Get-SCOMRule"       = "LastModified"
    "Get-SCOMTaskResult" = "LastModified"
    "Get-SCOMAlert | Get-SCOMAlertHistory"  = "TimeAdded"

    # mgmt
    'Get-SCOMManagementPack'    = "LastModified"
    'Get-SCOMResourcePool'      = "LastModified"
    'Get-SCOMUserRole'          = "LastModified"
    'Get-SCOMRMSEmulator'       = "LastModified"
    'Get-SCOMManagementServer'  = "LastModified"
    'Get-SCOMRunAsAccount'      = "LastModified"
    #'Get-SCOMGroup'             = "LastModified"
    'Get-SCOMRunAsProfile'      = "LastModified"

Second, i updated props.conf to set the timestamp to none for a custom sourcetype. The original props is applied against the wildcarded sourcetype, and is configured to use one of the date fields in the event itself. So I created the new sourcetype that is more specific and should therefore win the timestamp conflict.

[microsoft:scom:custom]
DATETIME_CONFIG = NONE
TIME_FORMAT = 
TIME_PREFIX =
TZ = UTC

And finally, after configuring the inputs I wanted from the web, I manually set the sourcetype to the custom one in inputs.conf and restarted Splunk.

[powershell://_Splunk_TA_microsoft_scom_internal_used_Prod Metrics]
index = tester
schedule = 0 0 6 ? * *
script = & "$SplunkHome\etc\apps\Splunk_TA_microsoft-scom\bin\scom_command_loader.ps1"  -groups "monitor","override","rule" -commands "get-scomgroup" -server "SCOM Prod" -loglevel DEBUG
sourcetype = microsoft:scom:custom
disabled = 0

I don't think this is ideal and maybe not the best approach, but it's working for our needs. If I had more time, I think I would have tried to find where in the script to put some logic to determine which field to use for the timestamp (including current time) and written a separate field for the timestamp to each event. Then use that field in props for all events. That would give us more flexibility.