How Splunk Helped Yodlee Improve Performance and Incident Response
•
0 gefällt mir•3,519 views
Yodlee Customer Presentation
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie How Splunk Helped Yodlee Improve Performance and Incident Response
Ähnlich wie How Splunk Helped Yodlee Improve Performance and Incident Response (20)
Mehr von Splunk
Mehr von Splunk (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
How Splunk Helped Yodlee Improve Performance and Incident Response
- 2. 2 About Yodlee • Leading technology and applicaFons plaGorm powering digital financial services • 950 companies, including 12 of the largest US banks subscribe to the Yodlee plaGorm • Yodlee soluFons transform financial innovaFon, improve digital customer experiences, and deepen customer engagement • HQ in Redwood City, CA – Global offices London and Bangalore
- 3. 3 About Me • Akshay Sethi - Director of Performance and Service Architecture • Manage the performance team, product tesFng, and performance tesFng • Assist in service architecture design, requirements, and vendor assessment for all operaFons iniFaFves
- 4. 4 Before Splunk Expansion • Every outage required searching through 20+ server logs to correlate events • Event correlaFon took hours or longer • Needed to enable the site reliability team responsible for producFon, upFme, and resiliency Needed to decrease MTTR
- 5. 5 Geng started with Splunk • Started with a 50-100 gig license in ~2010 • Teams began to realize the value of Splunk and was leveraged across teams • Found value in log aggregaFon and search capabiliFes • Started with troubleshooFng use cases “Teams realized the value of Splunk and started using it for projects!”
- 6. 6 Splunk Expansion " Needed to expand Splunk usage to include all producFon server logs " Data OperaFons team using splunk for troubleshooFng and data aggregaFons – Comfortable and familiar with Splunk capabiliFes " IdenFfied an opportunity to expand Splunk usage
- 7. The Splunk Advantage • Tried a small POC with the ELK stack • Retrieving, indexing, and structuring the data took a lot of effort • Splunk out of the box was easy to get up and running • Didn’t want 10 people implemenFng one soluFon • Leveraged Splunk online tool for sizing number of disks and indexers needed for a given number of GB per day / retenFon period “When you include all the man hours of implemenFng a new soluFon, It made more sense to go with Splunk.”
- 8. Splunk at Yodlee • Using Splunk for over 5 years • Currently 700 Gig License • Two teams using Splunk • Data operaFons team • Account AggregaFon team • Data sources include Oracle DB Connector App, linux server and custom add logs • Queries every minute, live dashboard and alerFng • Currently monitoring 4-5 databases • Currently monitoring 20 servers 8
- 9. Splunk as the core of the Yodlee PlaGorm • No more manual grepping through logs aner applicaFon failures • Planning to add JBOSS logs from producFon environment including access logs, server logs, and custom logs • Plan to start to Splunking addiFonal DB connectors, and network logs • Plan to monitor 150+ servers
- 12. 12 ExecuFve Level ReporFng " SLA reports, run access logs through Splunk to get execuFve summary " Measure server response Fme " Able to directly correlate informaFon with customer acFvity
- 13. 13 Splunk Enterprise Security " Splunk Enterprise Security (ES) cluster separate from main cluster " License of around 100 gigs " Splunk use expanded to the security team " Using ES for incident invesFgaFon and response, IPS ideas, and monitoring firewalls
- 15. 15 Key Take Aways ① Splunk can be leveraged across mulFple teams ② Started with the troubleshooFng use case and expanded into security, and monitoring producFon environments ③ Geng started with Splunk is easy!
- 16. 16 Best PracFces " Learn from other users – Splunk Lives – .Conf – Online EducaFon " You don’t need a large team, but you need a plan – Consider total cost of ownership of new tools
- 17. 17 What’s Next " Currently seng up a new Splunk cluster with 7 indexers " This cluster will process up to 800GB of data a day " Need to add all the addiFonal data sources from all producFon servers and network devices " Seng a separate and smaller Enterprise Security cluster for security monitoring
- 18. Thank You
Hinweis der Redaktion
- Envestnet, Inc. (NYSE:ENV) is a leading provider of unified wealth management technology and services to investment advisors. Our open-architecture platforms unify and fortify the wealth management process, delivering unparalleled flexibility, accuracy, performance, and value. Envestnet solutions enable the transformation of wealth management into a transparent, independent, objective, and fully-aligned standard of care, and empower advisors to deliver better outcomes. Envestnet | Yodlee is a leading technology and applications platform powering dynamic, cloud-based innovation for digital financial services. More than 950 companies, including 12 of the 20 largest U.S. banks and hundreds of Internet services companies, subscribe to the Envestnet | Yodlee platform to power personalized financial apps and services for millions of consumers. Envestnet | Yodlee solutions help transform the speed and delivery of financial innovation, improve digital customer experiences, and deepen customer engagement. Envestnet | Yodlee is headquartered in Redwood City, CA with global offices in London and Bangalore. For more information, visit www.yodlee.com. So Yodlee is financial platform company, so we do account aggregation and personal finance management products. And basically, I'm going to give you an overview and you can cut this down to how much ever you want. So we have banks, you know. We -- our biggest customers are financial institutions, so we help them aggregate accounts for their customers, right? So we work as a SaaS company for them. And if you want, if you want, you know, like a marketing maybe, as example. So I can get that I guess from our marketing
- and that's when we actually thought, "You know what, we actually need to go and expand our usage of Splunk to include the use case of where we can get all of our production server log into Splunk." And that's where, you know, I got involved with this project and we went ahead and we pushed for getting Splunk. So we knew the capabilities, right? Because we’d all -- some people within the organization were already using it. Our cluster wasn’t as big, it was pretty small but then we already saw the value of what we can do so we decided to go ahead and make a bigger purchase and actually size it so that it's big enough to gather all of our production server logs.
- So the main -- the main thing is we have a lot of like spikes that we see in production sometimes and downtimes, right, when some application fails. And when the application fails, it's actually running across -- it doesn't run across one server. It runs across maybe like 15 different instances running on three or four different servers, right? And then when something fails, you have to actually go and look at each log and see which component fails and what time and where it failed and actually change, like, piece together the sequence of events that happened for something to fail, right? So, for us to do that right now, we have to go into each log, run a grip command, get all the timestamps, see if it's actually the right log that you're looking into, and then do that across four or five different servers and across 20 instances, like 20 JBOS instances for example. And even then, it's tough to get the data reliably, right? You can't see it one place. You see it in 20 different screens.
- So the main -- the main thing is we have a lot of like spikes that we see in production sometimes and downtimes, right, when some application fails. And when the application fails, it's actually running across -- it doesn't run across one server. It runs across maybe like 15 different instances running on three or four different servers, right? And then when something fails, you have to actually go and look at each log and see which component fails and what time and where it failed and actually change, like, piece together the sequence of events that happened for something to fail, right? So, for us to do that right now, we have to go into each log, run a grip command, get all the timestamps, see if it's actually the right log that you're looking into, and then do that across four or five different servers and across 20 instances, like 20 JBOS instances for example. And even then, it's tough to get the data reliably, right? You can't see it one place. You see it in 20 different screens.
- Excuse me. So the main -- the main thing is we have a lot of like spikes that we see in production sometimes and downtimes, right, when some application fails. And when the application fails, it's actually running across -- it doesn't run across one server. It runs across maybe like 15 different instances running on three or four different servers, right? And then when something fails, you have to actually go and look at each log and see which component fails and what time and where it failed and actually change, like, piece together the sequence of events that happened for something to fail, right? So, for us to do that right now, we have to go into each log, run a grip command, get all the timestamps, see if it's actually the right log that you're looking into, and then do that across four or five different servers and across 20 instances, like 20 JBOS instances for example. And even then, it's tough to get the data reliably, right? You can't see it one place. You see it in 20 different screens.