[Cisco Ise] Parse TACACS accounting start_time/stop_time with sub-second epoch precision - #19894
Conversation
robester0403
added
bugfix
|
Pinging @elastic/integration-experience (Team:Integration-Experience) |
|
👀 I have started reviewing the PR |
Elastic Docs Style Checker (Vale)Summary: 1 suggestion found 💡 Suggestions (1): Optional style improvements. Apply when helpful.
The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
![vera-review-bot[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/3297022?s=60&v=4){kind=small}
|
👀 I have started reviewing the PR |
Vera Review BotFor the current commit state, I did not find any issues. 🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
🚀 Benchmarks reportTo see the full report comment with |
andrewkroh
left a comment
andrewkroh
left a comment
There was a problem hiding this comment.
Consider using a script processor to centralize and document the approach (prior art). It's probably more readable. Something like this then a single date processor that works on UNIX_MS. It eliminates the digit counting but uses a regex per doc.
- script:
description: >-
Normalize the epoch to milliseconds regardless of source unit (s / ms / µs / ns).
Cisco ISE TACACS+ accounting emits nanoseconds; older data uses seconds.
lang: painless
if: ctx.cisco_ise?.log?.avpair?.start_time instanceof String
source: |
def s = ctx.cisco_ise.log.avpair.start_time;
if (s == "0" || !(s ==~ /^\d+$/)) { return; }
long v = Long.parseLong(s);
if (v >= 1000000000000000000L) { v /= 1000000L; } // ns -> ms
else if (v >= 1000000000000000L) { v /= 1000L; } // µs -> ms
else if (v < 10000000000L) { v *= 1000L; } // s -> ms
ctx.cisco_ise.log.avpair.start_time = v;
| field: cisco_ise.log.avpair.stop_time | ||
| pattern: '^(\d{13})\d+$' | ||
| replacement: '$1' | ||
| if: ctx.cisco_ise?.log?.avpair?.stop_time instanceof String && ctx.cisco_ise.log.avpair.stop_time.length() > 13 |
There was a problem hiding this comment.
start_time has a != "0" guard. stop_time does not. Align them.
| - gsub: | ||
| tag: gsub_cisco_ise_log_avpair_start_time_18d7aae2 | ||
| field: cisco_ise.log.avpair.start_time | ||
| pattern: '^(\d{13})\d+$' |
There was a problem hiding this comment.
None of the new processors have a description. The digit-count magic needs to be explained.
| <181>Mar 20 12:01:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:01:20.528 +00:00 0018415782 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ConfigVersionId=78, Device IP Address=198.51.100.11, NetworkDeviceName=DEVICE_NAME_DUMMY, Type=Accounting, Privilege-Level=0, Service=Login, User=USER_DUMMY, Port=/dev/pts/3, Remote-Address=console, Authen-Method=TacacsPlus, AVPair=timezone=GMT, AVPair=task_id=375, AcctRequest-Flags=Stop, Service-Argument=shell, AcsSessionID=HOSTNAME_DUMMY/SESSION_ABC123/SESSION_DEF456, SelectedAccessService=Default Device Admin, RequestLatency=1, Step=13006, Step=15049, Step=15008, Step=15048, Step=22084, Step=13035, NetworkDeviceGroups=Device Type#All Device Types#Cisco, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=All Platforms#All Platforms#LAB#ACCESS, NetworkDeviceGroups=Location#All Locations#Site-B, CPMSessionID=CPM_DUMMY_001, TotalAuthenLatency=1, ClientLatency=0, Network Device Profile=Cisco, Location=Location#All Locations#Site-B, Device Type=Device Type#All Device Types#Cisco, IPSEC=IPSEC#Is IPSEC Device#No, All Platforms=All Platforms#All Platforms#LAB#ACCESS, Response={AcctReply-Status=Success; }, | ||
| <181>Mar 20 12:03:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:03:20.528 +00:00 0018415783 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ConfigVersionId=78, Device IP Address=198.51.100.12, NetworkDeviceName=DEVICE_NAME_DUMMY, Type=Accounting, Privilege-Level=0, Service=Login, User=USER_DUMMY, Port=/dev/pts/4, Remote-Address=EEM, Authen-Method=TacacsPlus, AVPair=timezone=GMT, AVPair=task_id=376, AcctRequest-Flags=Stop, Service-Argument=shell, AcsSessionID=HOSTNAME_DUMMY/SESSION_XYZ123/SESSION_XYZ456, SelectedAccessService=Default Device Admin, RequestLatency=1, Step=13006, Step=15049, Step=15008, Step=15048, Step=22084, Step=13035, NetworkDeviceGroups=Device Type#All Device Types#Cisco, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=All Platforms#All Platforms#LAB#ACCESS, NetworkDeviceGroups=Location#All Locations#Site-C, CPMSessionID=CPM_DUMMY_002, TotalAuthenLatency=1, ClientLatency=0, Network Device Profile=Cisco, Location=Location#All Locations#Site-C, Device Type=Device Type#All Device Types#Cisco, IPSEC=IPSEC#Is IPSEC Device#No, All Platforms=All Platforms#All Platforms#LAB#ACCESS, Response={AcctReply-Status=Success; }, | ||
| <181>Mar 20 12:05:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:05:20.528 +00:00 0018415784 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ConfigVersionId=79, Device IP Address=198.51.100.13, NetworkDeviceName=DEVICE_NAME_DUMMY, Type=Accounting, Privilege-Level=1, Service=Login, User=USER_DUMMY, Port=/dev/pts/5, Remote-Address=203.0.113.55, Authen-Method=TacacsPlus, AVPair=timezone=GMT, AVPair=task_id=377, AcctRequest-Flags=Stop, Service-Argument=shell, AcsSessionID=HOSTNAME_DUMMY/SESSION_IP123/SESSION_IP456, SelectedAccessService=Default Device Admin, RequestLatency=1, Step=13006, Step=15049, Step=15008, Step=15048, Step=22084, Step=13035, NetworkDeviceGroups=Device Type#All Device Types#Cisco, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=All Platforms#All Platforms#LAB#ACCESS, NetworkDeviceGroups=Location#All Locations#Site-D, CPMSessionID=CPM_DUMMY_003, TotalAuthenLatency=1, ClientLatency=0, Network Device Profile=Cisco, Location=Location#All Locations#Site-D, Device Type=Device Type#All Device Types#Cisco, IPSEC=IPSEC#Is IPSEC Device#No, All Platforms=All Platforms#All Platforms#LAB#ACCESS, Response={AcctReply-Status=Success; }, | ||
| <181>Mar 20 12:07:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:07:20.528 +00:00 0018415785 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ConfigVersionId=79, Device IP Address=198.51.100.14, NetworkDeviceName=DEVICE_NAME_DUMMY, Type=Accounting, Privilege-Level=1, Service=Login, User=USER_DUMMY, Port=tty0, Remote-Address=203.0.113.56, Authen-Method=TacacsPlus, AVPair=timezone=GMT, AVPair=task_id=378, AVPair=start_time=1585222245000000000, AVPair=elapsed_time=127, AVPair=stop_time=1585222372000000000, AcctRequest-Flags=Stop, Service-Argument=shell, AcsSessionID=HOSTNAME_DUMMY/SESSION_NS123/SESSION_NS456, SelectedAccessService=Default Device Admin, RequestLatency=1, Step=13006, Step=15049, Step=15008, Step=15048, Step=22084, Step=13035, NetworkDeviceGroups=Device Type#All Device Types#Cisco, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, Location=Location#All Locations#Site-E, Response={AcctReply-Status=Success; }, |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: medium path: packages/cisco_ise/data_stream/log/_dev/test/pipeline/test-pipeline-tacacs-accounting.log:23
The new epoch-normalization script has four unit branches (s/ms/µs/ns) but the added test only covers nanoseconds; add fixtures for the second/millisecond/microsecond paths so each branch is exercised.
Details
The added script normalizes start_time/stop_time from seconds, milliseconds, microseconds, or nanoseconds to a millisecond epoch via four branches. The only test line added feeds nanosecond values (start_time=1585222245000000000, stop_time=1585222372000000000), so the s (v<1e10, *1000), ms (pass-through), and µs (>=1e15, /1000) branches are never validated by the pipeline test. A future regression in any of those branches would not be caught.
Recommendation:
Add TACACS accounting fixtures that carry start_time/stop_time in the other units so every branch resolves to the same instant, e.g.:
<181>Mar 20 12:09:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:09:20.528 +00:00 0018415786 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ..., AVPair=start_time=1585222245, AVPair=stop_time=1585222372, ...,
<181>Mar 20 12:11:20 HOSTNAME_DUMMY CISE_TACACS_Accounting 0000000001 1 0 2026-03-20 12:11:20.528 +00:00 0018415787 3302 NOTICE Tacacs-Accounting: TACACS+ Accounting STOP, ..., AVPair=start_time=1585222245000, AVPair=stop_time=1585222372000, ...,
and extend the -expected.json so both resolve to 2020-03-26T11:30:45.000Z / 11:32:52.000Z, matching the nanosecond case.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
Review summaryIssues found across the latest commits 2be9d23 — 1 low
Issues found across earlier commits 8b2255d — 1 low
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
TL;DRThe failed Buildkite step did not reach the PR’s Cisco ISE pipeline changes. It failed during CI setup while Remediation
Investigation detailsRoot CauseThe job failed in the setup fallback in The PR diff only changes Evidence
Verification
Follow-up
What is this? | From workflow: PR Buildkite Detective Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. |
|
✅ All changelog entries have the correct PR link. |
💚 Build Succeeded
History
|
|
Tick the box to add this pull request to the merge queue (same as
|
|
Package cisco_ise - 1.32.8 containing this change is available at https://epr.elastic.co/package/cisco_ise/1.32.8/ |
2 participants
Proposed commit message
Parse TACACS accounting start_time/stop_time with sub-second epoch precision
In the
logdata stream, Cisco ISE TACACS accounting emitsstart_time/stop_timeAVPairs as nanosecond epoch values (e.g.start_time=1782407978339676873), but the pipeline parsed them asUNIX(seconds). The result overflowed to year+292278994, which Elasticsearch then rejected at index time — socisco_ise.log.avpair.start_time/stop_timewere silently_ignoredand lost.Checklist
- [ ] I have verified that all data streams collect metrics or logs.changelog.ymlfile.- [ ] I have verified that Kibana version constraints are current according to guidelines.- [ ] I have verified that any added dashboard complies with Kibana's Dashboard good practicesRelated issues
Partially Resolves: #19832
Screenshots