DOCSLIB.ORG

FULLTEXT01.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
FULLTEXT01.Pdf UPTEC F 18029 Examensarbete 30 hp Juni 2018 Investigation and Implementation of a Log Management and Analysis Framework for the Treatment Planning System RayStation Elias Norrby Abstract Investigation and Implementation of a Log Management and Analysis Framework for the Treatment Planning System RayStation Elias Norrby Teknisk- naturvetenskaplig fakultet UTH-enheten The purpose of this thesis is to investigate and implement a framework for log management and analysis tailored to the treatment planning system (TPS) Besöksadress: RayStation. A TPS is a highly advanced software package used in radiation Ångströmlaboratoriet Lägerhyddsvägen 1 oncology clinics, and the complexity of the software makes writing robust code Hus 4, Plan 0 challenging. Although the product is tested rigorously during development, bugs are present in released software. The purpose of the the framework is to allow the Postadress: RayStation development team insight into errors encountered in clinics by Box 536 751 21 Uppsala centralizing log file data recorded at clinics around the world. Telefon: A framework based on the Elastic stack, a suite of open-source products, is 018 – 471 30 03 proposed, addressing a set of known issues described as the access problem, the Telefax: processing problem, and the analysis problem. Firstly, log files are stored locally on 018 – 471 30 00 each machine running RayStation, some of which may not be connected to the Internet. Gaining access to the data is further complicated by legal frameworks Hemsida: such as HIPAA and GDPR that put constraints on how clinic data can be handled. http://www.teknat.uu.se/student The framework allows for access to the files while respecting these constraints. Secondly, log files are written in several different formats. The framework is flexible enough to process files of multiple different formats and consistently extracts relevant information. Thirdly, the framework offers comprehensive tools for analyzing the collected data. Deployed in-house on a set of 38 machines used by the RayStation development team, the framework was demonstrated to offer solutions to each of the listed problems. Handledare: Karl Lundin Ämnesgranskare: Carl Nettelblad Examinator: Tomas Nyberg ISSN: 1401-5757, UPTEC F 18029 v Sammanfattning Många fält har kunnat dra nytta av de förbättrade beräkningsmöjligheter moderna datorer erbjuder. Inom strålbehandling av cancerpatienter används idag avancerade datorprogram i form av dosplaneringssystem. Med deras hjälp kan behandlingar utformas så att tumörer nås av den ordinerade mängden strålning samtidigt som omgivande frisk vävnad skonas. Ett sådant dosplaneringssytem är RayStation, utvecklat av RaySearch. Program- varans komplexitet gör det svårt att skriva robust kod, och trots noggranna testpro- cedurer finns mjukvarufel i de versioner som används på kliniker. Ett viktigt led i att säkerställa produktens kvalitet är att bearbeta innehållet i de loggfiler som skrivs av RayStation under användning. RaySearch har idag väldigt begränsad tillgång till logginformation från kliniker. Åtkomsten försvåras av att de maskiner som an- vänds på kliniker ofta är isolerade och saknar internetanslutning. Dessutom ställer juridiska ramverk såsom HIPAA och GDPR hårda krav på hur klinikernas data ska hanteras. Syftet med det här projektet har varit att ta fram ett ramverk för loggfilshanter- ing, anpassat för RayStation och den miljö programvaran används i på kliniker. Utöver att lösa problemet med åtkomst ger ramverket exempel på hur informatio- nen i filerna kan bearbetas och analyseras. Det föreslagna ramverket är baserat på Elasticstacken, ett programpaket med öp- pen källkod som är ett populärt val för loggfilshantering. Ramverkets funktionalitet demonstrerades på RaySearchs utvecklingsavdelning där information från loggfiler på 38 maskiner samlades in och analyserades. vii Acknowledgements Firstly, I would like to thank my supervisor, Karl Lundin, as well as the rest of the RayStation Core development team at RaySearch, for aiding me in my work and for welcoming me into their office space. I will miss our morning meetings! Secondly, I would like to thank my subject reader, Carl Nettelblad, for enthusiasti- cally and meticulously reviewing draft upon draft, and for offering insightful com- ments during the writing process. ix Contents 1 Introduction 1 1.1 Background ..................................... 1 1.2 Purpose and tasks .................................. 1 1.2.1 Objective ................................... 2 1.2.2 Strategy ................................... 2 1.3 Delimitations .................................... 2 1.3.1 Focus on exceptions ............................ 2 1.3.2 Focus on functionality ........................... 3 1.3.3 Focus on compatibility with current and future releases ........ 3 1.4 Restatement of the problem ............................ 4 1.5 Restatement of the response ............................ 4 2 Technical background 5 2.1 Context ........................................ 5 2.1.1 A brief introduction to radiation therapy ................ 5 2.1.2 The role of treatment planning systems ................. 6 2.1.3 The role of RaySearch ........................... 7 2.1.4 Patient data privacy ............................ 7 The Health Insurance Portability and Accountability Act (HIPAA) . 8 The General Data Protection Regulation (GDPR) ............ 8 2.2 General log management concepts ........................ 9 2.2.1 Remote log analysis ............................ 10 2.2.2 Secure data transfers ............................ 10 2.2.3 A typical log message ........................... 11 2.2.4 Writing logs ................................. 11 2.2.5 Managing logs ............................... 12 2.3 The Elastic stack ................................... 13 2.3.1 Elasticsearch ................................. 13 Glossary and architecture ......................... 13 Indexing ................................... 13 Scaling and clusters ............................ 14 2.3.2 Logstash ................................... 14 Configuring Logstash ........................... 14 2.3.3 Kibana .................................... 15 2.3.4 Filebeat .................................... 17 2.4 Log files in RayStation ............................... 18 2.4.1 The RayStation Storage Tool log ..................... 18 2.4.2 The RayStation Index Service log ..................... 18 2.4.3 The RayStation Error log .......................... 19 2.4.4 The RaaS logs ................................ 19 x 3 Implementation 21 3.1 A: Setting up a grok pattern debugging pipeline ................ 22 3.2 B: Monitoring performance and collecting system data ............ 24 3.3 C1: Processing RayStation logs and managing multi-line messages ..... 26 3.4 C2: Centralizing logs in a virtual environment ................. 29 3.5 C3: Monitoring multiple workstations ...................... 31 3.6 C4: Simulating the clinic-to-RaySearch relationship .............. 32 3.7 C5: Finalizing the proof-of-concept solution ................... 33 4 Evaluation and results 35 4.1 File output impact on performance ........................ 36 4.2 Comparison of two logging libraries ....................... 37 4.3 Logstash performance with structured messages ................ 38 5 Discussion 39 5.1 Evaluation results .................................. 39 5.1.1 File output impact on performance ................... 39 5.1.2 Performance of logging libraries ..................... 40 5.1.3 Logstash performance with structured messages ............ 40 5.2 Security considerations ............................... 41 5.3 Privacy considerations ............................... 42 5.3.1 HIPAA .................................... 42 5.3.2 GDPR .................................... 43 5.4 Issues encountered during development ..................... 44 5.4.1 Managing clinic-side component configurations ............ 44 5.4.2 Logstash output limitations ........................ 45 5.4.3 Sparse indices vs. many indices ...................... 46 5.4.4 Clinics not fulfilling the minimal networking conditions ....... 46 6 Conclusion 49 6.1 The access problem ................................. 49 6.2 The processing problem .............................. 49 6.3 The analysis problem ................................ 49 1 1 Introduction 1.1 Background A treatment planning system (TPS) is a highly advanced software package that is used in radiation oncology clinics to generate radiation plans for cancer patients. The overall objective of the TPS is to create treatment plans that give the prescribed amount of absorbed radiation dose to the tumor, while sparing the surrounding healthy tissue as much as possible. RayStation is a TPS developed by RaySearch Laboratories. Used by 400 clinics in 25 countries, it is one of the most widely used treatment planning systems on the market [35]. The complexity of the software makes writing robust code challeng- ing. With the correctness of calculations conceivably carrying the weight of life or death for patients, bugs and otherwise unexpected states have to be given grave con- sideration during runtime, usually meaning the termination of the program. Even though the product is put through rigorous testing pre-release, bugs are present in live software. A key part in the current process for troubleshooting RayStation software prob- lems, and eliminating bugs, is to analyze the contents of log files written by the software during runtime and when the application crashes. Today, the information contained in these
Load more

Recommended publications
  • Build It with Nitrogen the Fast-Off-The-Block Erlang Web Framework
    Build it with Nitrogen The fast-off-the-block Erlang web framework Lloyd R. Prentice & Jesse Gumm dedicated to: Laurie, love of my life— Lloyd Jackie, my best half — Jesse and to: Rusty Klophaus and other giants of Open Source— LRP & JG Contents I. Frying Pan to Fire5 1. You want me to build what?7 2. Enter the lion’s den9 2.1. The big picture........................ 10 2.2. Install Nitrogen........................ 11 2.3. Lay of the land........................ 13 II. Projects 19 3. nitroBoard I 21 3.1. Plan of attack......................... 21 3.2. Create a new project..................... 23 3.3. Prototype welcome page................... 27 3.4. Anatomy of a page...................... 30 3.5. Anatomy of a route...................... 33 3.6. Anatomy of a template.................... 34 3.7. Elements............................ 35 3.8. Actions............................. 38 3.9. Triggers and Targets..................... 39 3.10. Enough theory........................ 40 i 3.11. Visitors............................ 44 3.12. Styling............................. 64 3.13. Debugging........................... 66 3.14. What you’ve learned..................... 66 3.15. Think and do......................... 68 4. nitroBoard II 69 4.1. Plan of attack......................... 69 4.2. Associates........................... 70 4.3. I am in/I am out....................... 78 4.4. Styling............................. 81 4.5. What you’ve learned..................... 82 4.6. Think and do......................... 82 5. A Simple Login System 83 5.1. Getting Started........................ 83 5.2. Dependencies......................... 84 5.2.1. Rebar Dependency: erlpass ............. 84 5.3. The index page........................ 85 5.4. Creating an account..................... 87 5.4.1. db_login module................... 89 5.5. The login form........................ 91 5.5.1.
    [Show full text]
  • Guide to Secure Software Development in Ruby
    Fedora Security Team Secure Ruby Development Guide Guide to secure software development in Ruby Ján Rusnačko Secure Ruby Development Guide Fedora Security Team Secure Ruby Development Guide Guide to secure software development in Ruby Edition 1 Author Ján Rusnačko [email protected] Copyright © 2014 Ján Rusnačko. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/ Legal:Trademark_guidelines. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
    [Show full text]
  • WEB2PY Enterprise Web Framework (2Nd Edition)
    WEB2PY Enterprise Web Framework / 2nd Ed. Massimo Di Pierro Copyright ©2009 by Massimo Di Pierro. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Copyright owner for permission should be addressed to: Massimo Di Pierro School of Computing DePaul University 243 S Wabash Ave Chicago, IL 60604 (USA) Email: [email protected] Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created ore extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. Library of Congress Cataloging-in-Publication Data: WEB2PY: Enterprise Web Framework Printed in the United States of America.
    [Show full text]
  • Making Story from System Logs with Elastic Stack
    SANOG36 18 - 21 January, 2021 Making story from system logs with stack [email protected] https://imtiazrahman.com https://github.com/imtiazrahman Logs syslog Audit SNMP NETFLOW http METRIC DNS ids What is Elastic Stack ? Store, Analyze Ingest User Interface a full-text based, distributed NoSQL database. Written in Java, built on Apache Lucene Commonly used for log analytics, full-text search, security intelligence, business analytics, and operational intelligence use cases. Use REST API (GET, PUT, POST, and DELETE ) for storing and searching data Data is stored as documents (rows in relational database) Data is separated into fields (columns in relational database) Relational Database Elasticsearch Database Index Table Type Row/Record Document Column Name Field Terminology Cluster: A cluster consists of one or more nodes which share the same cluster name. Node: A node is a running instance of elasticsearch which belongs to a cluster. Terminology Index: Collection of documents Shard: An index is split into elements known as shards that are distributed across multiple nodes. There are two types of shard, Primary and replica. By default elasticsearch creates 1 primary shard and 1 replica shard for each index. Terminology Shard 1 Replica 1 Replica 2 Shard 2 Node 1 Node 2 cluster Terminology Documents { • Indices hold documents in "_index": "netflow-2020.10.08", "_type": "_doc", serialized JSON objects "_id": "ZwkiB3UBULotwSOX3Bdb", "_version": 1, • 1 document = 1 log entry "_score": null, "_source": { • Contains "field : value" pairs
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Zope Documentation Release 5.3
    Zope Documentation Release 5.3 The Zope developer community Jul 31, 2021 Contents 1 What’s new in Zope 3 1.1 What’s new in Zope 5..........................................4 1.2 What’s new in Zope 4..........................................4 2 Installing Zope 11 2.1 Prerequisites............................................... 11 2.2 Installing Zope with zc.buildout .................................. 12 2.3 Installing Zope with pip ........................................ 13 2.4 Building the documentation with Sphinx ............................... 14 3 Configuring and Running Zope 15 3.1 Creating a Zope instance......................................... 16 3.2 Filesystem Permissions......................................... 17 3.3 Configuring Zope............................................. 17 3.4 Running Zope.............................................. 18 3.5 Running Zope (plone.recipe.zope2instance install)........................... 20 3.6 Logging In To Zope........................................... 21 3.7 Special access user accounts....................................... 22 3.8 Troubleshooting............................................. 22 3.9 Using alternative WSGI server software................................. 22 3.10 Debugging Zope applications under WSGI............................... 26 3.11 Zope configuration reference....................................... 27 4 Migrating between Zope versions 37 4.1 From Zope 2 to Zope 4 or 5....................................... 37 4.2 Migration from Zope 4 to Zope 5.0..................................
    [Show full text]
  • Original.Pdf
    Rails Security Primer I am not a software security expert CVE? Common Vulnerabilities and Exposures Vulnerability A weakness that an attacker can use to exploit a system Exploit A piece of software that exploits a vulnerability to achieve unintended or unanticipated behavior CVE-2012-5664 SQL Injection Vulnerability SQL Injection Vulnerability …but only exploitable if you used Authlogic or find_by_* methods in a certain way A cookie like { "session_id" => "41414141", "user_credentials" => "Phenoelit", "user_credentials_id" => { :select=> " *,\"Phenoelit\" as persistence_token from users -- " } } …would create a query like this User.find_by_id(params[:user_credendtials_id]) …would create a query like this User.find_by_id(params[:user_credendtials_id]) User.find_by_id({:select =>"*,\"Phenoelit\" as persistence_token from users --"}) …would create a query like this User.find_by_id(params[:user_credendtials_id]) User.find_by_id({:select =>"*,\"Phenoelit\" as persistence_token from users --"}) SELECT *,"Phenoelit" as persistence_token from users -- FROM "users" WHERE "users"."id" IS NULL LIMIT 1 Blood in the water… CVE-2013-0155 CVE-2013-0156 CVE-2013-0269 CVE-2013-0333 CVE-2013-0155 "Unsafe Query Generation Risk in Ruby on Rails" def reset_password if (@user = User.find_by_token(params[:token])) @user.reset_password! render :json => 'Success' else render :json => 'Failure' end end # POST to http://localhost:3000/users/ reset_password with "{\"token\":[null]}" CVE-2013-0156 "Multiple vulnerabilities in parameter parsing in Action Pack" Content-Type:
    [Show full text]
  • ELK: a Log Files Management Framework
    ELK: a log files management framework Giovanni Bechis <[email protected]> LinuxCon Europe 2016 About Me I sys admin and developer @SNB I OpenBSD developer I Open Source developer in several other projects searching through log files, the old way $ man 1 pflogsumm $ grep [email protected] /var/log/maillog | awk '{print $1 "-" $2 "-" $3;}' $ grep -e 'from=.*@gmail\.com' /var/log/maillog | grep "550" \ | awk {'print $1 "-" $2 "-" $3 " " $7 " " $10 " " $11 " " $13;}' $ vi logparser.sh $ git clone https://github.com/random/parser_that_should_work $ man 1 perltoc $ man 1 python searching through log files, the old way $ cssh -a 'mylogparser.py' host1 host2 host3 host4 | tee -a /tmp/parsedlogs.txt $ man syslogd(8) searching through log files, the new way ELK open source components I Beats: collect, parse and ship I Logstash: collect, enrich and transport data I Elasticsearch: search and analyze data in real time I Kibana: explore and visualize your data ELK closed source components I Watcher: alerting for Elasticsearch I Shield: security for Elasticsearch I Marvel: monitor Elasticsearch I Graph: analyze relationships Elasticsearch I open source search engine based on lucene library I nosql database (document oriented) I queries are based on http/json I APIs for lot of common languages, (or you can write your own framework, is just plain http and json) Elasticsearch: security I not available in open source version, you need Shield I Elasticsearch should not be exposed on the wild, use firewalling to protect your instances I manage security on your
    [Show full text]
  • Azure Forum DK Survey
    #msdkpartner #msdkpartner Meeting Ground Rules Please post your questions in the chat – We aim to keep QnA at the end of each session Please mute yourself to ensure a good audio experience during presentations This meeting will be recorded #msdkpartner Today's Agenda 08:30 - 08:35​ Welcome​ 08:35 - 09:15 Best of Build 09:15 - 10:00​ Top 5 Reasons to chose azure (vs. on-premise) 10:05 - 10:25​ Azure in SMB ​ 10:25 - 10:30​ Closing #msdkpartner #msdkpartner Hello! I’m Sherry List Azure Developer Engagement Lead Microsoft You can find me at @SherrryLst | @msdev_dk DevOps with Azure, GitHub, and Azure DevOps 500M apps and microservices will be written in the next five years Source: IDC Developer Velocity 100x 200x 7x 8x faster to set up a more frequent fewer failures on more likely to have dev environment code deployments deployments integrated security Source: DORA / Sonatype GitHub Actions for Azure https://github.com/azure/actions Azure Pipelines AKS & k8s support YAML CI Pipelines YAML CD Pipelines Elastic self-hosted agents Community and Collaboration In modern applications 90% of the code comes Your Code from open source Open Source Most of that code lives on GitHub Sign up for Codespaces Preview today https://github.co/codespaces Security and Compliance 70 Security and Compliance 12 56 10 42 7 LOC (M) LOC 28 5 Security Issues (k) Issues Security 14 2 Lines of code Security threats 0 0 Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr Jul Oct Jan Apr 2015 2015 2015 2016 2016 2016 2016 2017 2017 2017 2017 2018 2018 2018
    [Show full text]
  • Web Development Frameworks Ruby on Rails VS Google Web Toolkit
    Bachelor thesis Web Development Frameworks Ruby on Rails VS Google Web Toolkit Author: Carlos Gallardo Adrián Extremera Supervisor: Welf Löwe Semester: Spring 2011 Course code: 2DV00E SE-391 82 Kalmar / SE-351 95 Växjö Tel +46 (0)772-28 80 00 [email protected] Lnu.se/dfm Abstract Web programming is getting more and more important every day and as a consequence, many new tools are created in order to help developers design and construct applications quicker, easier and better structured. Apart from different IDEs and Technologies, nowadays Web Frameworks are gaining popularity amongst users since they offer a large range of methods, classes, etc. that allow programmers to create and maintain solid Web systems. This research focuses on two different Web Frameworks: Ruby on Rails and Google Web Toolkit and within this document we will examine some of the most important differences between them during a Web development. Keywords web frameworks, Ruby, Rails, Model-View-Controller, web programming, Java, Google Web Toolkit, web development, code lines i List of Figures Figure 2.1. mraible - History of Web Frameworks....................................................4 Figure 2.2. Java BluePrints - MVC Pattern..............................................................6 Figure 2.3. Libros Web - MVC Architecture.............................................................7 Figure 2.4. Ruby on Rails - Logo.............................................................................8 Figure 2.5. Windaroo Consulting Inc - Ruby on Rails Structure.............................10
    [Show full text]
  • Fiz: a Component Framework for Web Applications
    Fiz: A Component Framework for Web Applications John K. Ousterhout Department of Computer Science Stanford University Abstract Fiz is a framework for developing interactive Web applications. Its overall goal is to raise the level of programming for Web applications, first by providing a set of high-level reusable components that simplify the task of creating interactive Web applications, and second by providing a framework that encourages other people to create addi- tional components. Components in Fiz cover both the front-end of Web applications (managing a browser-based user interface) and the back end (managing the application's data). Fiz makes it possible to create components that encapsulate complex behaviors such as Ajax-based updates, hiding many of the Web's complexities from applica- tion developers. Because of its focus on components, Fiz does not use mechanisms such as templates and model- view-controller in the same way as other frameworks. ger and more useful structures. We will release Fiz in 1 Introduction open-source form and hope to build a user community Although the World-Wide Web was initially conceived that creates an ever-increasing set of interesting com- as a vehicle for delivering and viewing documents, its ponents, which will make it dramatically easier to cre- focus has gradually shifted from documents to applica- ate applications that advance the state-of-the-art in Web tions. Facilities such as Javascript, the Document Ob- interactivity. ject Model (DOM), and Ajax have made it possible to offer sophisticated interactive applications over the The rest of this paper is organized as follows.
    [Show full text]
  • Thomas Holloway Resume
    Thomas Holloway Austin, TX / 786-512-2964 / [email protected] nyxtom.dev / github.com/nyxtom / linkedin.com/in/thomas-holloway Senior Software Developer - Netcuras Inc. - Austin, TX - Nov 2015 - Present Technical lead and core contributor for implementing d3.js dashboards designed to solve the problem of infrastructure monitoring without a complicated user experience. ○ Built a dashboard capabilities system to monitor 1000s of devices with automated discovery, metrics aggregation, inferable widgets, plugins and system/company-wide JSON queryable YAML definitions ○ Wrote plugins for Netapp, VMWare, Meraki, MongoDB, Elastic, PostgreSQL, Netflow, Syslog, TCP, and UDP within a distributed collector architecture. ○ To handle Netflow/Syslog traffic I implemented a backlog capable Node.js stream followed by debugging, instrumenting, and profiling with cpu tracing and heap snapshots to maintain consistent throughput and handle network connectivity issues. To provide customers with high level visibility of network traffic, I wrote a number of different visualizations, top lists, and search aggregation queries for the dashboard UI. ○ Integrated Mapbox for visualizing 100s of devices in a hierarchical clustered layout ○ Built a connected graph in d3.js with a force-graph layout to provide visibility of SNMP networks ○ Improved responsiveness of web app from reading through React and Aurelia’s source code to understand and build upon on cooperative scheduling and binding behaviors with cached queries, jsonpath expression templates, virtualized components, and web workers (JavaScript, HTML/CSS, Aurelia, React.js, MongoDB, Redis, TCP/IP, REST, Elastic, D3.js, AJAX, Node.js, Express.js, Python, Go, LevelDB, TCP/IP, Jenkins, Ansible, Shell, Cent OS, VMWare, Netflow, Syslog, UDP, SNMP, JSONPath, Webpack, Babel) Creator - Nuvi.com - Salt Lake City, UT - 2011 - 2014 Launched social media analytics platform for +1000s of brands processing +1000000s of tweets, facebook posts, web articles within high fidelity visualizations, reporting, and dashboard UI.
    [Show full text]