Ni week 2018 LLAMA presentation
•Télécharger en tant que PPTX, PDF•
2 j'aime•559 vues
OO: LLAMA: Leveraging Object-Oriented Programming for Designing a Logging Framework
Recommandé
Contenu connexe
Tendances
Tendances (15)
Similaire à Ni week 2018 LLAMA presentation
Similaire à Ni week 2018 LLAMA presentation (20)
Plus de DMC, Inc.
Plus de DMC, Inc. (20)
Dernier
Dernier (20)
Ni week 2018 LLAMA presentation
- 2. OO: LLAMA: Leveraging Object-Oriented Programming for Designing a Logging Framework
- 3. LLAMA
- 4. Jesse Batsche Project Manager, DMC Christian Owen Systems Engineer, DMC
- 5. Established in 1996, DMC serves customers worldwide from offices in Chicago, Boston, Denver, Houston, New York, Reno, Seattle, and St. Louis. employees & growing 170+ DMC Overview
- 6. Industries Served Energy & Utilities Printing Automotive Food & Beverage Semiconductor Chemical Oil & Gas Engineering Specialty Machinery Consumer Goods Packaging Machinery Programming Telecommunications Defense Contracting Pharmaceutical Test & Measurement
- 7. Our NI Certifications 12 Certifications 4 Certifications 4 Certifications DMC has partnered with National Instruments since 1997 DMC’s team of certified LabVIEW engineers is one of the largest in the country 1 Certification
- 8. Areas of Expertise Manufacturing Automation & Intelligence Test & Measurement Automation Microsoft Consulting Services Custom Software & Hardware Development
- 9. Today we are NOT talking about… Logging?
- 10. Today we ARE talking about: Event Logging. Execution Trace Logging.
- 11. Session Outline • Why do we need a logging tool? • What makes a good logging tool? • Review community and industry options • How could such a tool be programmed? • Where do we go next?
- 12. Why Do We Need A Logging Tool? • Essential to debugging and monitoring deployed applications (no development environment) • Case study : Remote debug of Transmission EOL Tester in factory • Bridging the gap : User stories <-> Log files <-> Code execution
- 13. Why Do We Need A Logging Tool? • Supplements and fills gaps in built in LabVIEW debug tools • Debugging parallel operations • Highlight execution and breakpoints will change execution speed • Probes aren’t convenient for iterative calls • Event logging is always watching
- 14. What Makes A Good Logging Tool? • Easy to use • Simple API • Low barrier to entry, easy to integrate into applications, small footprint • Lightweight • Minimal impact on application performance • Configurable • Configurable at run time and after building • Easy to Extend • Easy to “plug in” new features
- 15. What Makes A Good Logging Tool? • Organized Output • Categorization or grouping of Entries • Timestamped • Significance or Subsystem • Easy to read, parse, search • Widely Accessible • PC or RT • Development or Runtime • Cross target
- 16. • Provides LIVE and HISTORICAL feedback What Makes A Good Logging Tool?
- 17. Your Thoughts? • What are other characteristics that a good logging tool should have?
- 18. What’s Available? • NLog (for .NET) • Supports multiple targets • Structured logging and categorization by severity • NI Desktop Execution Trace toolkit • Excellent for profiling memory and performance • Runs outside of LabVIEW (better for diagnosing crashes) • LabVIEW Community Tools • Logger by Field R&D Services, LLC • LabQT LGPL Open Source Library Logger • …
- 19. How could such a tool be programmed? • A practical discussion of LabVIEW programming techniques
- 20. LLAMA • LLAMA Logs AlMost Anything _(ツ)_/¯ • Design Intent • Pursue the ideals discussed earlier • Keep a simple task simple • DMC is sharing LLAMA (full source code) for you to download
- 21. Developer API Enqueue LLAMA Message.lvclass (Log Entry, Config, Shutdown, …) LLAMA Daemon (Queued Message Handler) Publish LLAMA Target.lvclass (Text File, PC Console, RT Console, …)
- 22. Live / Historical Feedback • Console Log target provides live feedback • File targets can be used to capture historical information
- 24. Easy to Use • Straightforward API • Small code footprint, portable • Easy to integrate into an application • Drop Daemon • Drop API calls
- 26. LLAMA: Overview • The LLAMA daemon • Launched at startup, runs in background • Consumes API messages • Hangs on to an array of Target objects and a queue reference • The LLAMA Messaging VIs • Enqueues Message objects, which are consumed by the daemon • Configure, Log Entry, Shutdown • Low overhead
- 27. Lightweight • Heavy lifting occurs in daemon • API calls are merely enqueueing a message object • Daemon handles messages as time allows • A quick benchmark : Log string to Text File • 2 steps • Generate string to log : enqueue • <2% of time (3.3 us) • Compose full log string, write to text file • 98% of time (185 us)
- 28. Organized Output • Categorization in terms of Severities • Trace Debug Info Warn Error Fatal • Categorization by functional area • Headers allow for simple sorting of entries • Timestamp and Log Level included here • Simplest Case : Text File • Flexible, easily searched/parsed • Extension Case : Structured (e.g. cluster) • Avoid string parsing, more compact representation
- 29. Configurable at Runtime/Post-Build • LLAMA can be configured to write to a number of log targets • Log targets can be added or removed without restarting application • Configuration can be updated after building
- 30. Categorized Output, Configurable Tool
- 31. Widely Accessible • Compatible with RT targets and PC targets • Can run in development environment and executables • Limitations • No native support for log consolidation between targets
- 32. Extensible • Example: Instead of string to a text file… We want CAN Frame Message to a Database Target • Creating a Message plug-in • Create a new child of Message and override “Process” method • Add a new VI to the API which enqueues the Message object • Creating a Target plug-in • Create a new child of Target and override “Log” and “Configure” methods
- 33. Where Do We Go Next? • More destinations via new Target child classes • Database • Structured TDMS execution trace • Cross-target consolidation • Syslog • Expanded API via new Message child classes
- 34. Audience Input • What would you find useful? • What have you done in your own logging toolchains?
- 36. Download and Login to the NIWeek Mobile App VIEW WEEKLY SCHEDULE FIND YOUR SESSION BUILD YOUR SCHEDULE More Information at ni.com/niweek
Notes de l'éditeur
- (2 – 3 minutes) Jesse and Christian introduce themselves I’m Jesse, I’ve been enjoying working with the NI platform for about 10 years as an engineer and project manager at DMC – designing custom test equipment, programming large scale applications, marketing NI solutions and leading teams of developers as a certified labview architect. I’m Christian Owen. I work for DMC … Test and Measurement team … CLD … 2 years of LabVIEW and NI hardware experience.
- While some companies may focus on one particular industry segment, on DMC we focus on technology platforms, and most notably here the NI platform. We help companies in almost any industry, like those shown here, to benefit from the capabilities of those platforms to meet their particular needs.
- MANUFACTURING AUTOMATION & INTELLIGENCE Our Manufacturing Automation offerings make your production systems more efficient, flexible, and reliable using the latest technologies. As premier automation integrators our manufacturing intelligence solutions provide you the information you need to make more effective business decisions. TEST & MEASUREMENT AUTOMATION Our Test & Measurement Automation Services help automate laboratory testing using the latest technologies. We deliver world class solutions to leaders in research, development, production, quality, and certification testing. We develop efficient, accurate, robust test systems, and the tools to leverage test data for effective results analysis. CUSTOM SOFTWARE & HARDWARE DEVELOPMENT We can help with your product or application development needs. Our services include product conception, custom electronic hardware development, application development for web, desktop, embedded, and mobile, and the development of developer tools (SDK, Drivers, API, etc.). MICROSOFT CONSULTING SERVICES DMC has been a certified Microsoft Gold Partner since 2005. Gold is an elite status that represents the highest level of expertise with Microsoft technologies. We excel at helping clients understand software capabilities, put structure around business processes, and extend & integrate software solutions using Microsoft-centric technologies (SharePoint, Office 365, Azure, CRM, .NET, etc.).
- I’ll start our discussion today with what we’re NOT talking about
- (2-3 minutes) In general, logging is a good way good way to debug deployed applications. Consider case where application is deployed, going onsite to debug isn’t desired CHRISTIAN Misaligned Timestamp Case Study DMC Developed an application used in production Used in production so Downtime = bad Production site was far away no remote access, so no debugging using EXE with debug enabled After a few weeks, user reported an issue timestamps misaligned; not something we had seen before We asked the user to send us logs classified as either “good” logs or “bad” logs By comparing good and bad logs side by side, we were able to determine what was going on in the application Logs bridged gap between the user’s story and what was happening in the application, and ultimately lead to a solution
- (2-3 minutes) logging is also helpful when standard debug tools (e.g. highlight execution, probes, breakpoints) won’t cut it. Consider case where lots of things running in parallel full system behavior is dependent on an ecosystem of processes each interacting with each other. You don’t want to stop or slow any of the loops What does event logging have in common with the eye of Sauron? Event logging is always watching. It’s always there, has your back to catch something that is unexpected, uncommon, or infrequent. Logs will tell the story you need to diagnose effectively. Has anyone been identified as a “Computer Whisperer” by the users?
- (5-10 minutes) EASY TO USE LIGHTWEIGHT Minimal impact on application: you want to know that the application behaves the same way with logging as without logging Heisenberg Uncertainty CONFIGURABLE Depending on whether things are running smoothly or not, you may be interested in a very high level narrative of what the application is doing, or a very detailed and verbose log. You may want log information being sent to different locations or formats for analysis. Need to be able to adjust this on the fly, in development and runtime environments. EASY TO EXTEND Extensible: different applications have different needs. A logging framework that allows a programmer to build in new features or targets (such as a database, emails) is able to adapt to those needs. Basically, have deliberate points of extensibility to accommodate future needs - Other things to talk about: notification service
- SENSIBLE OUTPUT output that allows one to quickly find what they’re looking for Categorization or grouping of Entries: - Different severities / tags - High level vs low level items - Different functional areas (different logging targets) WIDELY ACCESSIBLE Runs on RT and PC Remote connection to target (see debug console) Consolidate messages from multiple related targets
- PROVIDES LIVE AND HISTORICAL FEEDBACK Sometimes you care now. Sometimes you care about then.
- CHRISTIAN (2-5 minutes) Maybe talk about these three: NLog (common in .NET) Desktop trace toolkit (provided by NI) Logger (NI Tools Network) Lyndon: Ease of log retrieval is a major selling point for him. Cool features (that LLAMA doesn’t have) that I’ve found so far: Templating / Structured Logging, which allows a user to create and use different templates for log entries
- (10-15 minutes) I know what you’re all thinking and the answer is Yes. Yes that’s a recursive acronym. We’re working to RESOLVE that… but we just keep ending up back where we started. LLAMA fits the bill, so DMC uses it often Sharing LLAMA It will help demonstrate some practical techniques for making a Logging toolchain If don’t like the tool, you will hopefully walk away with a few useful tools to go find or build your own If you do like LLAMA and it fits your needs, you can download it and use it If you do like LLAMA but it doesn’t quite fit your needs, we’ll talk about points of extensibility, so you could download and mold it to your needs
- This is how things are set up If you’re familiar with Actor Framework, you will notice this is quite similar to AF. An actor that is sent a few messages and has a few nested actors. In our current implementation, it’s NOT AF, primarily to keep a toolchain super self contained.
- Jesse to work on this
- Then, talk about how we implemented ours, and let people know how they might go about implementing their own. We should probably spend a decent bit of time talking about OO stuff, as that’s the title. Maybe encourage people by telling them that it’s quite simple to build up the framework. Building up an OO logging framework is not difficult. What are it’s major components? Daemon (consumer) API (producer) Log Entry Configure Extensible: What are the benefits of making this thing OO? All the typical benefits of OO programming: Encapsulation (organization), abstraction (as long as it works, one don’t need to care how it works), clean extensibility (new targets can be implemented without needing too much knowledge of the entire framework), code resuse How did we design it using classes? Lightweight: Maybe discuss how much time it takes to run, and how we made it efficient Maybe: talk about some of the performance improvements Jesse made?
- Not RT compatible (though we can totally fix this)
- Not RT compatible (though we can totally fix this)
- Add picture for CAN Frame to Database
- Native multi-target coordination / co-registration Although, that can be done with a database, right?
- Attention Speaker: Remind your session attendees that the mobile app is the primary source for conference information.
- Attention Speaker: Remind attendees they can find session materials on the NIWeek 2018 mobile app, ni.com/niweek and ni.com/niweekcommunity.