vereza peatyn martall
Margorie Gomoran
And when I go to :3000/graphiql I can using the graphiql UI to run queries on my user service. If I send graphql queries to :3000/graphql I get a response, but if I send the same query to :8080/userService/graphql I get a 404. Further, if I try to hit the REST endpoints on localhost:3000 using the gateway like localhost:8080/v1/users/user/userId I get the expected response.
I am curious what the general take of the recent Netflix announcement is with regard to our ability to control the traffic. Announcement here . I have an opinion as to whether it is necessary, but that is another subject altogether.
It is clear there is only so much application ID that can occur if the data is encrypted, but can it be combined with URL rules to control the traffic? We would, for example, have to know all of the URLs/subnets that youtube (or Netflix) videos are streamed from. Is that even possible?
We have yet to implement any decryption, but I see that it is going to have to happen at some point. But if we implemented it, is anything going to be able to keep up with the decryption process when it is decrypting a bunch streaming data?
With decryption, you have access to the sub-functions within that application (ie: being able to tell the difference between netflix queue management and streaming, or the difference between facebook-posting and facebook-file-transfer).
Jared is absolutely correct regarding using decryption to enable inspection. To address the performance concern: whether or not decryption has an appreciable effect on your performance depends entirely on *how much* you are decrypting. Each platform has specific upper limits in terms of the maximum number of concurrent decrypted sessions. The additional overhead caused by decryption will depend on this volume. You can limit the scope of decrypted traffic using different criteria (e.g. URL category). This approach will let you inspect things that need to be, like youtube, facebook, etc. while not wasting resources on sessions that probably don't need to be (e.g. online banking, healthcare, etc).
It depends if Netflix just wants to protect the name of the content being watched, or if they really want hide the fact you watch Netflix at all. Like Jared said, you can see the domain name during the SSL/TLS handshake, so you will still be able to block Netflix if you want. After all, if a user cannot login to the main page, he won't be able to watch anything.
The problem I see is more with the QoS. The content is currently streamed from a lot of servers using domain names ending in *.nflxvideo.net. If Netflix encrypts those streams and change the domain name to something less obvious, the firewall will see it as generic encrypted traffic and the QoS rule for Netflix won't match, unless you have a decryption rule in place. I guess there will also be the option of simply giving a low priority to generic encrypted trafic.
Maybe a better example is: Someone logs onto Google.com, then goes to youtube via the google apps link. Unless I am missing something, the PA is seeing this traffic as SSL as the call to google is already encrypted.
Bob, that's a perfect example. If google uses *.google.com as a certificate for all of their properties (including youtube, gmail, google-search, google-hangouts, etc.) then it will become increasingly difficult to identify, inspect, and secure the traffic within that SSL tunnel without performing SSL decryption.
Last week I ran an ACC report for the top 25 applications. Netflix was #3 (university environment, so it's to be expected). Today, I ran the same report and Netflix (as an application) is no where to be found. I launched Netflix on my computer to generate some traffic and I'm not seeing it (I waited 20 minutes to make sure the session was ended and logged). I've tried searching, but I don't see any modifications to the application. Any reason this isn't showing up any more?
I have noticed quite a few incidences where netflix has been identified as web-browsing. Please make sure you are on the latest content version (463 being latest today) and test again as I see some improvements being reported. You may open a support case to follow the updates from bug 68271.
To include Eureka Server in your project, use the starter with a group ID of org.springframework.cloud and an artifact ID of spring-cloud-starter-netflix-eureka-server.See the Spring Cloud Project page for details on setting up your build system with the current Spring Cloud Release Train.
If your project already uses Thymeleaf as its template engine, the Freemarker templates of the Eureka server may not be loaded correctly. In this case it is necessary to configure the template loader manually:
The Eureka server does not have a back end store, but the service instances in the registry all have to send heartbeats to keep their registrations up to date (so this can be done in memory).Clients also have an in-memory cache of Eureka registrations (so they do not have to go to the registry for every request to a service).
By default, every Eureka server is also a Eureka client and requires (at least one) service URL to locate a peer.If you do not provide it, the service runs and works, but it fills your logs with a lot of noise about not being able to register with the peer.
The combination of the two caches (client and server) and the heartbeats make a standalone Eureka server fairly resilient to failure, as long as there is some sort of monitor or elastic runtime (such as Cloud Foundry) keeping it alive.In standalone mode, you might prefer to switch off the client side behavior so that it does not keep trying and failing to reach its peers.The following example shows how to switch off the client-side behavior:
Eureka can be made even more resilient and available by running multiple instances and asking them to register with each other.In fact, this is the default behavior, so all you need to do to make it work is add a valid serviceUrl to a peer, as shown in the following example:
In the preceding example, we have a YAML file that can be used to run the same server on two hosts (peer1 and peer2) by running it in different Spring profiles.You could use this configuration to test the peer awareness on a single host (there is not much value in doing that in production) by manipulating /etc/hosts to resolve the host names.In fact, the eureka.instance.hostname is not needed if you are running on a machine that knows its own hostname (by default, it is looked up by using java.net.InetAddress).
In some cases, it is preferable for Eureka to advertise the IP addresses of services rather than the hostname.Set eureka.instance.preferIpAddress to true and, when the application registers with eureka, it uses its IP address rather than its hostname.
Servo served Netflix for several years and is still usable but is gradually being phased out in favor of Spectator, which is designed to work only with Java 8.Spring Cloud Netflix provides support for both, but Java 8-based applications are encouraged to use Spectator.
Spring Boot Actuator metrics are hierarchical, and the metrics are separated only by name.These names often follow a naming convention that embeds key/value attribute pairs (dimensions) into the name (separated by periods).Consider the following metrics for two endpoints, root and star-star:
The first metric gives us a normalized count of successful requests against the root endpoint per unit of time.But what if the system has 20 endpoints and you want to get a count of successful requests against all the endpoints?Some hierarchical metrics backends would let you specify a wildcard, such as counter.status.200.*, that would read all 20 metrics and aggregate the results.Alternatively, you could provide a HandlerInterceptorAdapter that intercepts and records a metric such as counter.status.200.all for all successful requests irrespective of the endpoint, but now you must write 20+1 different metrics.Similarly, if you want to know the total number of successful requests for all endpoints in the service, you could specify a wildcard such as counter.status.2*.*.
Even in the presence of wildcarding support on a hierarchical metrics backend, naming consistency can be difficult.Specifically, the position of these tags in the name string can slip with time, breaking queries.For example, suppose we add an additional dimension to the earlier hierarchical metrics for an HTTP method.Then counter.status.200.root becomes counter.status.200.method.get.root (or post and so on).Suddenly, Our counter.status.200.* no longer has the same semantic meaning.Furthermore, if the new dimension is not applied uniformly across the codebase, certain queries may become impossible.This can quickly get out of hand.
Netflix metrics are tagged (in other words, they are dimensional).Each metric has a name, but this single named metric can contain multiple statistics and 'tag' key/value pairs, which allows more querying flexibility.In fact, the statistics themselves are recorded in a special tag.
Without any additional dependencies or configuration, a Spring Cloud based service autoconfigures a Servo MonitorRegistry and begins collecting metrics on every Spring MVC request.By default, a Servo timer with a name of rest is recorded for each MVC request, which is tagged with the following information:
If Spring AOP is enabled and org.aspectj:aspectjweaver is present on your runtime classpath, Spring Cloud also collects metrics on every client call made with RestTemplate.A Servo timer with a name of restclient is recorded for each MVC request, which is tagged with the following information:
In Spectator parlance, a meter is a named, typed, and tagged configuration, while a metric represents the value of a given meter at a point in time.Spectator meters are created and controlled by a registry, which currently has several different implementations.Spectator provides four meter types: counter, timer, gauge, and distribution summary.
90f70e40cf