cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
632
Views
5
Helpful
4
Replies
JonasKs
Beginner

ACI aaaModLR has unstructured data, and normal subscription events don't have IDs. This makes reliable event subscription hard

Hi,

 

Subscribing to events such as whenever an application profile changes like this works perfectly fine:

class/fvAp.json?subscription=yes

I get responses such as:

 

{
  'subscriptionId': [
    '72059964880715777'
  ],
  'imdata': [
    {
      'fvAp': {
        'attributes': {
          <trunkated response>
          'dn': 'uni/tn-Jonas/ap-Test-AP',
          'status': 'created',
        }
      }
    }
  ]
}

 

This is fine, but if I lose connection to the APIC or my service goes down, I have no control over potentially lost events (and only the lost events).

 

The solution is to subscribe to audit log events (aaaModLR). In this case the code E4211942 is for creation of Application Profiles.

https://apic-ip-address/api/node/class/aaaModLR.json?subscription=yes&query-target-filter=eq(aaaModLR.code,"E4211942")

This query gives us responses such as:

{
  'subscriptionId': [
    '72059964880715785'
  ],
  'imdata': [
    {
      'aaaModLR': {
        'attributes': {
<trunkated response> 'affected': 'uni/tn-Jonas/ap-Test-AP', 'cause': 'transition', 'changeSet': 'name:Test-AP, prio:unspecified', 'code': 'E4211942', 'created': '2021-06-22T15:47:18.211+02:00', 'descr': 'Ap Test-AP created', 'dn': 'subj-[uni/tn-Jonas/ap-Test-AP]/mod-4295026262', 'id': '4295026262', 'ind': 'creation', 'user': 'Jonas' } } } ] }

This response does have an id, 4295026262. This means, if our application crashes, all we need to know is the latest ID we received.

When our connection is established to the APIC again, we can query for events newer than this event:

https://apic-ip-address/api/node/class/aaaModLR.json?query-target-filter=and(eq(aaaModLR.code,"E4211942")gt(aaaModLR.id,"4295026261"))&order-by=aaaModLR.created|desc

 

How ever, the aaaModLR events are unstructured and hard to work with. For a change event on the description, it looks like this:

{
  'totalCount': '1',
  'imdata': [
    {
      'aaaModLR': {
        'attributes': {
<trunkated response> 'affected': 'uni/tn-Jonas/ap-Test2-AP', 'cause': 'transition', 'changeSet': 'descr:contact name:Jonas, if not available: Torbjorn, name:Test2-AP, prio:unspecified', 'code': 'E4211942', 'created': '2021-06-22T15:57:20.665+02:00', 'descr': 'Ap Test2-AP created', } } } ] }

Since `changeSet` isn't structured, we have to convert a string into structured data. This can be very annoying when we have examples as the one above.

 

 

The string representation of the changeSet is:

descr: <description>, name:<object name>, ...

but, as we can see, our description also contains name:. This makes regex handling hard and has a potential to be a source of bugs.

 

The best solution for us would be to have IDs on all objects, so that we could subscribe to application profiles like this:

class/fvAp.json?subscription=yes&query-target-filter=ge(fvAP.AuditId, "4295026262")

or that the aaaModLR contained structured data:

{
  'attributes': {
    'descr': 'contact name:Jonas, if not available: Torbjorn',
    'name': 'Test2-AP',
    'prio': 'unspecified'
  }
}

Since neither of these are possible, there don't seem to be any good way of actually reliably obtaining data, ensuring no events are lost. (Except storing it all in our own database and cross checking at intervals, which also isn't really a good option)

 

Since ACI has some type of event system internally (Kafka?), I was wondering if it's possible to hook onto this manually? Any suggestions for any other, better alternatives than the ones I've described?

 

 

4 REPLIES 4
JonasKs
Beginner

Bump

Bump

Sergiu.Daniluk
VIP Advocate

Hi @JonasKs 

To me it looks like a bug. All audit log events have an eventId.

If you do not see it in the response you get, then it's a bug. You should open a TAC case.

 

Stay safe,

Sergiu

Event logs (aaaModLr) do, but they don’t have structured data - hence this request.