As reported before, almost all event logs are highly incomplete, and it's very hard to get an immediate idea what kind of device caused the event:
Ok, this happened around the update to drop 5 - but it's a wonderul example on the (sorry to say) mostly useless infromation here in the event list. Fun enough, the similar stuff is repeated in the management summary reports, too.
Mandatory infomation in an event viewer is:
A. To immediate identify the device:
2. IP Address
3. Device Type
4. Location, ... where available
B. Event details:
"Firmware was upgraded on the device." - interesting...but useless! What was the old firmware version? New firmware version? What has triggered the firmware update?
Device ID 54:75:0D:nn:nn:nn ... A MAC address might be very useful for uniquely identifiying a device interface in a network, but this is the least useful (not to say useless) information to identify a device to a human, sitting sosmewhere on the Internet.
Remember: We have no simple way to search for the Device ID (nor antyhing else...) in the Dashboard nor locate it in the Topology map. Locate a MAC address in an environment forh 50, 100, or more devices? Sort the Dashbord list on the device ID, and use your eyes - or copy the Device ID, and put it to a filter, and click apply. By far to much work, for simple data readily available in the cloud.
Not even the browser based text find (CTRL-F) works - Yes: The only advantage of Flex/Flash: The generated output can look nice. But for a Web application, it's rubbish. I hope Cisco makes us of Web 2.0 / Ajax /HTML5 technologies instead in a next drop.
I am tracking all these enhacements as part of the work that needs to be done to Notifications and Events.
Thanks for your feedback. You will see it change sooner rather than later.
By the way Kurt, we do have a Search capability in the Dashboard, we call it "Filter". Is this not doing what you need? How can we improve it?
This is a known problem. The event mechanism is, for lack of a better term, primary
key based pointer. The event itself doesn't contain anything except for pointers
to get the information somewhere else. Each event would/will have to go to different
places to get more information about the event.
It would help a lot if you could click on this popup to get to the relevant
places in the database. I'll see if there is something we can do there.
Also, each event type has mandatory fields. A firmware upgrade
event has the fields customerid, siteid and deviceid. We also have the ability
to add extra fields, I was looking at the database entries for this one, there is
a field that isn't being displayed, which is the new firmware version being installed.
We can probably do that, the problem with it is that the description (in this case 'ev_firmware')
has no 'english' translation. So the prompt would read 'ev_firmware 184.108.40.206'.
I appreciate that this is frustrating and we will make this more useful! Thanks,
Strikes me that the information we're currently preseting in event lists is diagnostics related with deveng/devtest engineers as the intended audience. Back in RCDN, we have the tools to decipher what's currently presented in the event list. I think we need a partner-facing event list UI and a separate the existing engineer-facing (Cisco SBSC/SvcOps/DevEng/DevTest)-facing event list UI.
So the event list as-is is useful to us. Not as much to partners. Kurt's point is well-taken as youve pointed out. The partner needs raw event data translated to content and format to which partners can start immediately performing useful diagnostics on their own with the tools they have at hand. Kurt's suggestion is a good starting point, I think. That list might allow them to remediate problems without a support call. If that is insufficient, an escalation to Cisco SBSC might be effected in which SBSC engineers, Svc Ops engineers and our dev eng/devtest teams can use the existing detailed list and our access to internal tools as pointers to problem detail not exposed (nor do they necessarily wish it tobe exposed) to the partner. In short,... two event lists. One with raw diags used as tools for escalation troubleshooting, second as tool for partners to start diagnosing as soon after the event as possible.
The Device ID with the MAC address is technically a very logical index to identify the device.
But this information is simply of ZERO help when we will receive event information in the future from our customer sites! We must know what kind of device this is, paired with the configured hostname, and possibly paired with the drop 5 comment field. What a difference, when a core switch or a NAS goes down - compared to a IP phone somewhere on a users desk, that is simply relocated.
It can't be required we have to check the portal for each and every event!
While discussing, we recieved this event:
Event Id 3765400
Event Type MON.HOSTSTATE
Event Time/Date 2010-09-29 13:57:26
Event Message Host TwonkyMedia Server (
Customer ID 1149.ciscovar.com
Site ID 1
Host State UP
Here we have a slighly better idea what this device is. Ha, it's a TwonkyMedia Server. Hm. Obviously, the message is derived from a UPnP announcement. Again - and I have reported this before - it's about the last information we're keen to know: For us, this is a Cisco NSS324 Network Attached Storage Unit in the first priority, and not a Twonky server!
Now let's say this is one of the three last events, and it will end in the manager report! Good luck explaining the boss, why we ave a device in the monitoring, that seems to be used mainly to stream digital media...
I insist to review and enhance the device detection by using additional resources like DNS (reverse lookup), instead of ushowing UPnP information. It can't be, every non-stripped Windows workstation running Windows Media Player is shown as a Windows-Media-Player-Sharing, an entertainment class, and a mediaserver device instead. Unless your customer is a DJ or a radio station - this is simply a bad joke! Hey, this is an expensive Windows workstation, holding software for many thousand bucks on top of the OS, and is used wo work with....!!!
The posting subject was choosen intentional. We the astronauts out here must be able to judge from every event message sent by SMS or e-mail, what physical and logical device this is - os we can evaluate, what has to be done - without calling Houston.
Yes Marcos, there is a filter - but this is again to complex. How do we pass this information? Cut and paste from the e-mail might work on a PC, but is not an opton on a mobile device. Instead, we must be able to jump direct from the event (showin on the portal everything we have listed here already) to the device. When checking the "Event History" on the portal, we have at least the link to the device - this stime on the IPv4 address - again another information, that does not tell us much about the unit.
A simple request: Instead of sending a HTML formatted event notification, please add _all_ information the cloud knows about the device. Plus some more to be discovered.
Sorry for being picky - but the event system as implementend is ... of a very limited usage only.
Good stuff Kurt. Thanks, and please keep it coming.
Your point is well taken on the usefulness and quantity of information delivered in the current notifications. We have much work to do in this area before release.
Superb job Mike! Looking forward to where Windows workstations (with WMP up and running) will be no longer entertainment devices, too. Just let us know - drop ba drop - when we shall run a new discovery (hope that will be enough), or reinitialize the TBA from scratch and associate to a (new?) customer.